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

Transcription

1 Qatar Ministry of Interior - Public Key Infrastructure Business and Corporate CA Certification Practice Statement Issue : 1.2 Issue date : 19 October 2014 Status : Approved page 1 of 54

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 54

3 Detailed contents 1 Introduction Overview Document name and Identification PKI Participants Certificate Usage Policy Administration Definitions, acronyms and references 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 Certificate Re-key page 3 of 54

4 4.8 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 CERTIFICATE, CRL PROFILES Certificate Profile page 4 of 54

5 7.2 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 54

6 1 Introduction 1.1 Overview This Certification Practice Statement (CPS) describes the certification practices that apply to the digital certificates issued by the Business and Corporate Certification Authority (CA), which is operated by the Ministry of Interior (MoI) of the State. 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 MoI as well as any CSP willing to operate in the state of Qatar, must be licensed by the CSPs-PMA and then certified by the Qatar National Root CA before issuing certificates or providing services related to electronic signatures. The Business and Corporate CA is one of the MoI subordinates CAs certified by the Qatar National Root CA. MoI Subordinate CAs deliver national Public Key Infrastructure (PKI) certification services that enable citizens, residents and corporate organizations to conduct secure electronic transactions. The Business and Corporate CA is responsible, mainly for issuing and managing certificates for corporates and business organizations in the state of Qatar. Corporates and business organizations can leverage these certificates in building their own PKI-based solutions offering secure electronic transactions for their employees/customers. This CPS covers the issuance and controls surrounding the following types of certificates and their associated key pairs: Business and corporate certificates for end-users acting on behalf of the corporate or business organization they work for; this category comprises two certificates with the below purposes: o Encryption certificate - used for secure and for data/document encryption o Signing Certificate - used to produce digital signatures on digital transactions/document signing. Certificates issued for MoI Online Certificate Status Protocol (OCSP) Responder - certificates issued for MoI OCSP responder to sign OCSP responses related to the certificates issued by this CA. This CPS is maintained by MoI and is made available online along the applicable CP via MoI PKI web portal Qatar Public Key Infrastructure (QPKI) Hierarchy The figure below illustrates the PKI operated by MoI. The National Root Certification Authority (NR-CA) is the top authority in Qatar with regard to digital certification services offered in the country. The NR-CA issues top level certificates to MoI Subordinate CAs (Citizen and Resident CA, Business and Corporate CA and infrastructure CA). page 6 of 54

7 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 outlined as follows: Registration service: It verifies the identity and, if applicable, any specific attributes of end-entities applying for certificates. The results of this service are relayed 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 and Revocation management service: It processes requests and reports relating to revocation for determining the appropriate action to be taken. The results of this service will be available through the certificate validity status service. Certificate validity status service: It provides certificate validity status information to relying parties. This must be based upon certificate suspension/revocation lists. 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 - Business and Corporate CA CPS and is referred in related documents as QATAR-MoI-Business and Corporate CA CPS" Identification Alphanumeric OID The Object Identifier of this CPS is page 7 of 54

8 1.3 PKI Participants Several parties are involved during the lifecycle management of digital certificates issued by this CA. They include: Certification Authorities (CA) Policy Authority Operational Authority Registration Authorities Local Registration Authority (LRA) Subscribers Relying Parties These participants and their roles are described in the following sections Certification Authorities For this CA, the Certification Authority issues Business and Corporate certificates for corporates and business end-users in addition to OCSP response signing certificates. This includes the following tasks: Issuing and managing certificates Publishing encryption certificates to a public repository that is accessed by Relying Parties Issuing and publishing Certificate Revocation Lists (CRLs) to a public repository that is accessed by Relying Parties Pushing CRLs to MoI OCSP responder Policy Authority A PKI board is established by 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 is constituted of individuals with security clearance who will be overall responsible for: 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 on actions to be taken as a result of deficiency Organizing key ceremonies including allocating members to key ceremonies Specifying and maintaining overall Disaster Recovery and Business Continuity plan for this CA Operational Authority The Operational Authority (OA) comprises individuals who are responsible for the operations of MoI PKI in accordance with this CPS. page 8 of 54

9 The following roles have been defined for the operations of MoI PKI including this CA: CA Master user - responsible for the configuration and maintenance of hardware and software for the CA; start-up and cessation of CA services and the initial creation of accounts for PKI Officers. CA Security Officer - responsible for managing 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 - responsible for managing the subscriber s initialization process; the creation, renewal or revocation of certificates and the distribution of tokens (where applicable). PKI administrator 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 The RAs represent individuals and systems who 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: - Certificates through MOI RA: Business and Corporate entities may request key pairs and certificates from MoI, which they received on PKI tokens (e.g., smartcards). MoI OA plays the role of the RA for these types of certificates. This includes certificate issuance and revocation. - Certificates through LRA: MoI OA, in its role as an RA for the Business and Corporate CA, registers LRA officers to the system so that these officers could then generate and manage digital certificates of their community of users. See LRA section in this policy document for further details. - Virtual ID certificates through LRA: Business and Corporate entities may receive virtual ID certificates from MoI PKI. These certificates are managed by a dedicated LRA acting on behalf of an entity. See the LRA section of this policy for further details. - OCSP certificates: The OA acts as the RA for MoI OCSP responder certificate lifecycle management Local Registration Authority (LRA) MoI offers LRA services to organizations willing to manage certificates lifecycle for their own communities. The organizations willing to use the LRA service will have to sign an agreement with MoI through which it commits to use the LRA service from MoI in accordance with the applicable CP and this CPS. page 9 of 54

10 The organization, which opts for the LRA service, appoints an LRA officer who will be enrolled to this CA by MoI RA as an administrator having the credentials to enroll and manage the subscribers of the organization that the LRA officer represents. The duties of the LRA officer are as follows: Collecting and validating subscribers identity data Conforming to the rules of this CP and related CPS of the Business and Corporate CA Issuing and managing certificates of the organization s subscribers Subscribers Subscribers of this CA are Qatari Citizens and residents receiving identity certificates and acting on behalf of business organizations they adhere to. 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 Relying parties are public, private business organizations and corporates within the state of Qatar in addition to citizens and residents of the country Other Participants There are no other participants for this CA. 1.4 Certificate Usage Appropriate Certificate Use A Qatari Citizen or resident acting on behalf of a Corporate or Business organization applies and receives two key pairs and related certificates as follows: - Encryption key pair with related encryption certificate used for: o Secure o Document/data encryption - Signature key pair and related certificate used for: o Authentication o Signing digital transactions This CA also issues OCSP certificates intended for MoI OCSP responder. page 10 of 54

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 document. Using certificates for other purposes is explicitly prohibited. 1.5 Policy Administration Organization Administering the Document This document is administered by 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: [email protected] Person Determining CPS Suitability for the Policy The MoI PA determines the suitability of any CPS for MoI PKI policy Ref [QATAR-MoI-PKI CP] CPS Approval Procedures A dedicated process of the PA involves the PA officer reviewing the initial version of this CPS and any subsequent updates. Amendments shall either be in the form of a document containing an amended form of the CPS or an update notice. The PA officer approves the changes and issues an approval note to MOI PKI board. The CPS update is formally approved through a meeting of the MoI PKI board. 1.6 Definitions, acronyms and references Definitions and acronyms The following sections contain the definitions of terms and acronyms. The source of a definition is cited when available. Activation data - Secret information, other than cryptographic keys, that are required to operate cryptographic modules that need to be protected, for example, a PIN, a password or pass-phrase, or a manually held key share. page 11 of 54

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 indicate 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 which 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 54

13 MoI-IS - Ministry of Interior s Information Services Department OA - Operational Authority, the team within MoI-ISD in charge of operating MoI PKI OID - Object Identifier, a value (distinguishable from all other such values) which is associated with an object. (ITU-T X680) It is referred in many RFCs and used in the ASN.1 encoding of certificates. OCSP - Online Certificate Status Protocol. PA - Policy Authority PED - PIN Entry Device PIN - A Personal Identification Number or password used to protect private information and keys on PKI 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 Renewal - Issuance of a new certificate to the subscriber without changing the subscriber s public key or any other information in the certificate page 13 of 54

14 Repository - A trustworthy system for storing and retrieving certificates or other information relevant to certificates. RSA - The acronym for the inventors of RSA algorithm - Ron Rivest, Adi Shamir and Leonard Adleman SCEP - Simple Certificate Enrolment Protocol Secret Shares - A set of devices, smartcards, 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] Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework [RFC5280] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [ETSI ] ETSI EN V1.1.1 ( ) Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; page 14 of 54

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

16 2 Publication and Repository Responsibility 2.1 Repositories The MoI operates the repositories for the Subordinate CAs. The core repository is an LDAP directory server where various PKI related data is published including CA certificates and Certificate Revocation Lists (CRLs). The MoI also has a replica of the core LDAP referred to as public LDAP that is published and made available to relying 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 MoI public LDAP All encryption public key certificates issued by this CA Certificates of MoI OCSP responder 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) as soon as they are issued CA and OCSP certificates Encryption Certificates CRLs The following rules apply for CRLs issued this CA: At minimum, CRLs are refreshed every 24 hours. The lifetime of CRLs is set to 26 hours (24 hours update period + 2 hours preupdate period). 2.4 Access Controls on Repositories Public read-only access to the CP, CPS, certificates and CRLs published. Access control techniques are implemented by the MoI to protect the Public LDAP and PKI portal from unauthorized addition or modification of any published data. page 16 of 54

17 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 follows: CN=Business and Corporate Certification Authority, O=QECC, C=QA Subscribers Certificates issued for business (private) companies through MoI RA: cn=<individual unique name organization unique registration number>, ou = corporates, o = QECC, c = QA Certificates issued for corporate (non-private) organizations through MoI RA: cn=<individual unique name organization meaningful unique name >, ou = corporates, o = QECC, c = QA Certificates issues to business (private) companies through LRA: cn=<individual unique name>, ou=< organization unique registration number >, ou = corporates, o = QECC, c = QA Certificates issues to corporate (non-private) organization through LRA: cn=<individual unique name>, ou=< organization meaningful unique name >, ou = corporates, o = QECC, c = QA Virtual ID certificates issued to business (private) companies through LRA: cn=<individual unique name>, ou=< organization unique registration number >, ou = VSC_corporates, o = QECC, c = QA Virtual ID certificates issued to corporate (non-private) organization through LRA: cn=<individual unique name>, ou=< organization meaningful unique name >, ou = VSC_corporates, o = QECC, c = QA MoI OCSP Responder certificates: cn = MoI OCSP, cn Business and Corporate Certification Authority, o = QECC, c = QA Meaningful Names For certificates issued to individuals, names are meaningful since the CN contains the name of the subscriber. For certificates issued to the MoI OCSP responder, the names are meaningful and indicate the OCSP name (MoI OCSP) Anonymity and Pseudonymity of Subscribers This CA does not support the issuance of anonymous certificates. page 17 of 54

18 3.1.4 Rules for Interpreting Various Name Forms No stipulation - this section intentionally left blank Uniqueness of Names Unique subject DNs are enforced as follows: For certificates issued for individuals: o Business (private) entities: The unique company registration number is used as part of the certificate DN to uniquely identify the company. o Corporate entities (non-private such as government entities): A convention for a meaningful name representing uniquely the individual and the entity he works is enforced by the MoI. For certificates issued for the MoI OCSP responder: The OCSP responder unique name is included in the subject DN to ensure uniqueness 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 Certificates issued for individuals: o PKI tokens (smartcard, USB token, etc.) - the token or smartcard that signs a proof of possession included in the PKIX-CMP request submitted to this CA. o Virtual ID certificates - the subscriber s keys are generated and stored securely within the VSC platform, however the VSC platform signs a Proof-of-Possession (POP) and include it as part of the PKIX-CMP request submitted to this CA. Certificates issued for the MoI OCSP: Certificate Signing Requests (CSR) generated by the OCSP responder contains a Proof-of-Possession (POP) of the private key as part of the PKCS#10 request file submitted to this CA Authentication of Organization Identity Organizations are verified through the certificate enrolment process Authentication of individual identity The below points describe the rules that apply for authentication of certificate applicants: For certificates issued for corporate cards by MoI RA, the subscriber s identity is established as follows: page 18 of 54

19 o The subscriber appears in person and brings supporting documents related to the application of the certificate, hence providing evidence to establish the relation between the applicant and the organization o The MoI RA validates the association between the applicant and the organization For certificates issued for PKI tokens by LRA: The subscriber s identity verification is done according to the applicable corporate/organization business rules. For Virtual ID certificates: Each enrolment channel has its own Identification and authorization approach: o o Hukoomi Portal: Virtual ID account holder identity is established through PKI authentication procedure involving his eid card Hukoomi Portal validates the association between the applicant and the organization through an automated process MoI Self-Service Kiosk: Virtual ID account holder identity is verified through fingerprint verification procedure involving his eid card The Self-Service Kiosk validates the association between the applicant and the organization o VSC LRA: The subscriber s identity authentication is done according to the applicable corporate/organization business rules. For certificates issued to the OCSP responder: The certification process is initiated by an authorized OCSP administrator under the supervision of the MoI PA. A dedicated operational key ceremony is documented by the MoI involving relevant OA roles Non-verified subscriber information All subscriber information written in the certificate issued by MoI CAs is verified by the applicable RA Validation of Authority No stipulation since only a physical person may be certified Criteria for Interoperation No stipulation. page 19 of 54

20 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-Key after revocation Identification after revocation is performed as in initial registration Identification and Authentication for Revocation Request Revocation requests are validated as follows: Revocation of Business and Corporate certificates through MoI RA: o The subscriber or an authorized representative visits the MoI-IO in order to request the temporary or permanent blocking of his/her PKI token or VSC. o The MoI-IO officer authenticates the subscriber s identity through a face-toface verification in addition to identity verification involving the individual s ID card. o The MoI-IO officer requests the subscriber to fill and sign a revocation request form. o The MoI-IO officer sends a copy of the revocation request form to the MoI OA team and archive the original revocation request form o The MoI RA officer revokes the subscriber s certificates o The CA generates an updated CRL and publishes it to the MoI public repository Revocation of Business and Corporate certificates (including VSC certificates) through an LRA: o The LRA receives a revocation request from the subscriber o The LRA validates the identity of the subscriber for a revocation request through a dedicated organization process o The LRA records the revocation request according to the organization s business rules o The LRA officer revokes the subscriber s certificates o The CA generates an updated CRL and publishes it to the MoI public repository Revocation of OCSP certificates: The revocation is conducted as part of a PKI process internal to the MoI and is approved by MoI PA. This process involves communications with relying parties in order to update them with the OCSP certificate revocation. page 20 of 54

21 4 Certificate Life Cycle Management 4.1 Certificate Application Who Can Submit a Certificate Application For certificates issued for MoI RA: The MoI Information Security (MoI-IS) RA officer submits the certificate application as part of the corporate card issuance process. For VSC certificates: The LRA officer submits the application for the certificate implicitly when submitting the VSC enrolment request for a corporate employee. For certificates issued by corporates for PKI tokens (smartcard, USB token, etc.): The LRA submits the certificate application for a corporate employee during the PKI token issuance process. For OCSP responder certificate: An authorized OCSP administrator can submit a certificate request to the OA Enrolment Process and Responsibilities The process of issuing certificates for corporate cards through the MoI RA is a twostage process as follows: o o Stage 1: Smartcard Issuance Stage 2: Certificate Issuance through the MoI-IS Officer Stage 1: Smartcard Issuance a) The applicant (corporate end-user) submits a signed corporate card application form to the MoI-IS b) An officer from the MoI-IS checks the applicant s qualification for card issuance by performing background checks against data held by its own and other law enforcement agency databases c) The MoI-IS prints and issues the smartcard d) The applicant or their authorized representative collects the card from the MoI-IS Stage 2: Certificate Issuance through the MoI-IO Officer a) The applicant signs the subscriber agreement. b) The MoI-IS RA officer creates the subscriber s DN in the MoI LDAP and enables it for certificate Issuance. c) The MoI-IS RA officer submits the certificates enrollment request through a dedicated RA application. d) The RA application communicates with this CA in order to issue end-user certificates. e) The CA generates the certificates and sends back to the RA application that installs the certificates on the card. f) The applicant is now a registered subscriber, who will receive a smartcard, an initial PIN label, a CD containing smartcard driver and a software for changing the PIN. page 21 of 54

22 g) The subscriber must immediately change their PIN using the provided software. The process for issuing Virtual ID (VSC) certificates through an LRA is performed as listed below: a) The applicant (Corporate or Business end-user) who requires a VSC steps to the VSC corporate administrator (VSC LRA officer) where the applicant signs a Subscriber Agreement. b) The LRA officer validates the applicant s identity fact-to-face and ensures the enrollment data is correct, in addition to following business rules endorsed by business policy, procedure and process. c) The LRA officer accesses a dedicated RA application in order to fill the VSC enrollment form after validating all data required for the enrollment. d) The VSC enrollment application registers the user in the VSC platform, generates user keys in the backend and then sends certificate requests to this CA in order to issue VSC certificates. e) The applicant then accesses the VSC enrollment application in order to set his permanent VSC password. f) The VSC enrollment communicates with this CA to retrieve the certificates and then save it along with the user s VSC account. Finally the VSC platform sends an SMS to the user s mobile declaring that the account is active. The process for issuing certificates for a PKI token (smartcard, USB token, etc.) through LRA is performed as follows: a) The applicant, who requires the PKI token with digital certificates, introduces himself to the local corporate RA officer where they sign a Subscriber Agreement. b) The LRA officer validates the applicant s identity fact-to-face and ensures the enrolment data is correct, in addition to following business rules endorsed by business policy, procedure and process. c) The LRA officer uses a dedicated RA application in order to fill the certificate enrollment form after validating all data required for the enrollment. d) The RA application communicates with this CA in order issue end-user certificates. e) The CA generates the certificates and sends back to the RA application which installs the certificates on the PKI token. f) The applicant is now a registered subscriber and is handed over his PKI token, Initial PIN label, a CD containing the device driver and change PIN software. g) The subscriber must immediately change the PIN using the supplied change PIN software. The process for issuing the OCSP responder certificate is as follows: a) The MoI OCSP Administrator requests a certification approval from the MoI PA b) The OCSP Administrator generates a key-pair and a certificate request on the OCSP platform page 22 of 54

23 c) The OCSP Administrator exports the certificate request and delivers it to the Business and Corporate CA administrator d) The Business and Corporate CA Administrators submit the certificate request to this CA and receives the certificate e) The CA Administrator delivers the certificate to the OCSP administrator f) The OCSP administrator imports the certificate to the OCSP responder platform 4.2 Certificate Application Processing Performing Identification and Authentication Functions As described in section Approval or Rejection of Certificate Applications The approval or rejection of certificates applications is done as follows: For certificates issued for through the MoI RA: The MoI RA officer approves or rejects the application for the certificate as part of the overall approval/rejection of the corporate card issuing process. For VSC certificates: The LRA officer approves or rejects the certificate application as part of the overall approval/rejection of the VSC enrolment process. For certificates issued by corporates for PKI tokens (smartcard, USB token, etc.): The LRA officer approves or rejects the certificate application as part of the overall approval/rejection of the PKI token issuance process. For certificates issued to OCSP: A certificate application is approved/rejected as part of the overall approval/rejection of the OCSP certification process Time to Process Certificate Applications No stipulation. 4.3 Certificate Issuance CA Actions during Certificate Issuance For certificates issued to PKI tokens (smartcard, USB token, etc.): The protocol is PKIX-CMP. The subscriber s chip generates a key pair and sends the public key to the CA. The CA constructs an X509v3 signing certificate as follows: o Constructs certificate DN as described in section o Checks that the DN does not already exist o Signs the signing certificate o Activates the issued certificate Simultaneously, the CA generates the encryption certificate as follows: page 23 of 54

24 o o o o o Generates the encryption key pair, then backup the private key Constructs an X.509v3 encryption certificate using the same DN constructed for the signing certificate Signs the encryption certificate Activates the issued certificate Publishes the certificate to the directory. Finally, the CA sends the decryption key along with the encryption, signing and CA certificates to the RA application. For Virtual ID certificates: The key-pairs are generated on the VSC backend server that sends the public keys to the CA for certification. The CA constructs an X509v3 signing and encrypting certificate as follows: o Construct certificate DN as described in section o Check that the DN does not already exist o Signs the certificates o Activates the issued certificates Finally, the CA sends the encryption, signing and CA certificates to the applicable RA application. For OCSP certificates: The OCSP administrator manually delivers the CSR file including the servers public key to the CA administrator. The CA administrator submits the CSR file directly to the CA that will sign and publish an OCSP certificate suitable for verification. The certificate is returned to the OCSP administrator Notification to the Subscriber by the CA of Issuance of Certificate For certificates issued to PKI tokens (smartcard, USB token, etc.): The applicant is notified immediately when the certificates are downloaded on the card. For Virtual ID (VSC) certificates: The applicant is notified by SMS when the certificates are issued and VSC account is active. For OCSP certificates: The OCSP administrator receives the certificate file once the certificate is issued. 4.4 Certificate Acceptance Conduct Constituting Certificate Acceptance The user confirms certificate acceptance upon signing a dedicated form. Not applicable for OCSP certificates Publication of the Certificate by the CA CA Certificates, Encryption certificates and OCSP will be published to the public repository (MoI public LDAP) as they are issued. page 24 of 54

25 4.4.3 Notification of Certificate Issuance by the CA to Other Entities No stipulation - this section intentionally left blank 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 consistent with this CPS. Comply with the terms of the subscriber agreement. Not use the private key until after the CA has issued, and the subscriber accepted the corresponding certificate. The subscriber must 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 (duration) validity period. Certificate Renewal is not supported by this CA. Only certificate re-key is supported. page 25 of 54

26 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 Circumstances leading to Certificate Re-key The (subscriber) individual, OCSP administrator is responsible for renewing their certificates. Certificates need to be renewed prior to the expiring date, otherwise it will not be validated by relying 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 26 of 54

27 4.9 Certificate Revocation and Suspension Circumstances for Revocation An individual or an authorized organization s representative may request a revocation of his certificate if: The PKI token (Smartcard, USB token, etc.) or its authentication details are lost or stolen. The PKI token is defective. The individual discovers or has reasons to believe that there has been a compromise of his private signing key. The information on the certificate is no longer accurate; for example a change of name or if an employee left his position at the organization. The corresponding PKI token is renewed before expiration and the token holder cannot surrender the token at renewal (in this case, the subscriber must first declare his former card as lost). The LRA of the organization shall revoke digital certificates corresponding to his organization when required by the organization s internal processes This CA will revoke the certificate upon: The death of the individual. The request of the individual or an authorized organization s representative. 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 individual has left the State of Qatar for more than 6 months. The individual has been imprisoned. The organization or the individual has been declared legally incompetent. On the other hand, this CPS does not provide provisions for revoking an OCSP certificate apart from the compromise of the OCSP key pair which is treated by the MoI as per its Disaster Recovery and Business Continuity procedures. The following sub-sections focus only on the revocation provisions that apply for individual certificates Who Can Request Revocation The individual, to whom the PKI token or VSC certificates were issued to, may request self-request revocation. Any relying party possessing evidence of compromise of the subscriber s certificate may request revocation from the MoI. Revocations are directly initiated by the MoI s RA officers in the following cases: o PKI token lost, stolen or defective before delivery o PKI token found by a third party page 27 of 54

28 o Individual is deceased and the PKI token is not found The LRA of the organization shall revoke digital certificates corresponding to his organization when required by the organization s internal processes. The MoI at its own discretion (if for instance a compromise is known for this CA key) Procedure for Revocation Request For Certificates issued through MoI RA: The RA procedure for user-certificate revocation is as follows: 1) RA looks up DN in a dedicated RA application 2) Selects the desired certificate 3) Selects Revoke this certificate 4) Enters revocation reason and submits it. For Virtual ID (VSC) Certificates: The LRA procedure for user-certificate revocation is as follows: 1) The LRA looks up the VSC account in VSC enrollment application 2) Selects Revoke Account 3) Enters revocation reason and submits it 4) The VSC enrollment application communicates with this CA to revoke the corresponding VSC certificates. For Certificates issued through LRA: The LRA procedure for user-certificate revocation is as follows: 1) The LRA looks up DN in a dedicated RA application 2) Selects the desired certificate 3) Selects Revoke this certificate 4) Enters revocation reason and submits it Revocation Request Grace Period There is no revocation grace period. Revocation requests are processed timely upon reception by the RA 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. page 28 of 54

29 The 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 responsibility to process certificates and to retrieve the 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 The OCSP is supported and is compliant with RFC 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 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. page 29 of 54

30 Operational Characteristics The 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). The 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 Policy and Practices Key escrow is not supported by MoI PKI Session Key Encapsulation and Recovery Policy and Practices No stipulation - this section intentionally left blank. page 30 of 54

31 5 FACILITY, MANAGEMENT and OPERATIONAL CONTROLS 5.1 Physical Controls Site Location and Construction All critical components of the PKI solution are located within a highly secure enclave within an MoI building. Access controls are in place to protect the PKI solution Physical Access Physical security controls include security guard controlled building access, man traps, biometric IRIS access and CCTV monitoring. These physicals 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 supplied 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 exposed to water damage Fire Prevention and Protection The enclave must be protected from fire, heat, and smoke detection equipment monitored on a 24*7*365. Fire suppression equipments 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 disposed. Reusable magnetic and optical media may be reused indefinably within the enclave Off-site Backup System backup sufficient to recover from system failure is made daily. Backup copies should be rotated to a secure off-site location. page 31 of 54

32 Backup media is stored in a location separate from the MoI s 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 that is enforced at the MoI s 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: CA operators responsible for the 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 in place ensure the principles of dual control and split knowledge that requires two or more individuals to perform 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 the necessary credentials that allow them to conduct their functions Roles Requiring Separation of Duties No individual may be assigned 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 32 of 54

33 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 provide refresher training and updates to its personnel to the extent and frequency required to ensure that such personnel maintain the required level of proficiency to perform their job responsibilities competently and satisfactorily 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 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. page 33 of 54

34 5.3.8 Documentation Supplied to Personnel Individuals are provided with sufficient documentation to define their duties. They also provided 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 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: page 34 of 54

35 Audit logs are reviewed regularly (at a minimum once a week) Identified issues and irregularities are 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 be 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 provide 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. 5.5 Records Archival Types of Records Archived This PKI archives records in accordance with the procedures described in the 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 page 35 of 54

36 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 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 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 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 a MoI offsite location by the same controls enforced on the primary backup Requirements for Time-stamping of Records No stipulation Archive Collection System (internal or external) No stipulation Procedures to Obtain and Verify Archive Information Personnel accessing archive information will only do so with a letter of authorization from The PA and OA director. Any personnel or MoI internal courier will sign acknowledgement for receipt of archive information Archive information carried between sites will be carried in a sealed container under lock and key Receiving personnel must verify that the archive is genuine and sign acknowledgement for receipt Personnel will make reasonable endeavor to maintain the chain of evidence page 36 of 54

37 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 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 the appropriate measures 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 CA s 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 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 activate the Disaster Recovery and Incident Handling procedure, 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 controls instigated before reestablishment of the CA. Re-establishing this CA operations after approval from the PA 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: page 37 of 54

38 Certificates Confidentiality private Keys CRLs Audit information The MoI will also 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 38 of 54

39 6 TECHNICAL SECURITY CONTROLS 6.1 Key Pair Generation CA Key Pair Generation This CA key pairs are generated within a Safenet Luna SA cryptographic hardware device that is security evaluated to FIPS 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 Subscriber Key Pair Generation Subscriber s private keys are generated as follows: Individuals signing keys: The keys are generated within the VSC platform or within the secure memory of a PKI token. Individuals encryption keys: o Encryption keys for e-id card are generated by the CA within the secure memory of the HSM. o Encryption keys for VSC are generated within the VSC platform within the secure memory of the VSC dedicated HSM. MoI OCSP signing: The key is generated within the secure memory of the OCSP dedicated HSM Private Key Delivery to Subscriber This CA generates private keys for encryption certificates stored on PKI tokens only. In this case, the encryption key pair along with the encryption certificate is delivered to RA applications as part of a certificate management communications based on PKIX-CMP protocol. This CA does not generate private keys for VSC or OCSP responder Public Key Delivery to Certificate Issuer For individual s certificates, Public Keys are delivered through PKIX-CMP standard protocol. For OCSP certificates, public keys will be encapsulated in a PKCS#10 certificate request produced by the OCSP administrator and delivered to the OA of this CA. page 39 of 54

40 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) Key Sizes This CA key pair is 2048 bit RSA. The Subscriber key is 2048 bit RSA except for corporate smartcard keys where the key size is 1024 bit 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 compliant hardware random number generator Key Usage Purposes (as per X.509 v3 key usage field) The Certificate will always contain a KeyUsage bit string in accordance with RFC Business and Corporate 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 Subscribers Signing Keys may be used to produce digital signatures on digital transactions and for document signing. The Certificate KeyUsage field will be set to: Key usage:: Bitstring {Digital signature} Encryption Key will be used for secure and for document encryption The Certificate KeyUsage field will be set to: Key usage:: Bitstring {Key Encipherment} Table 2: Subscriber s Key usage page 40 of 54

41 6.2 Private Key Protection and Cryptographic Module Engineering Controls Cryptographic Module Standards and Controls The CA generates their key pairs and store it within an HSM certified according to the rating specified in PKI token holders private keys are generated within a smartcard or a similar PKI token that is certified according to the rating specified in VSC key pairs are stored in an encrypted format using a master key, the master key is stored in a dedicated HSM certified according to the rating specified in OCSP responder generates and stores its own key pairs within its dedicated HSM Private Key Multi-Role Control The CA s private keys are supervised using 3 OA trusted personnel Private Key Escrow Key escrow is not supported by MoI PKI Private Key Backup This CA s private key is backed on PKI 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 Private Key Archival No stipulation Private Key Transfer Into or From a HSM The CA s private key backup is securely maintained within the HSM (token-to-token cloning) and at no time does the private key get exposed Private Key Storage on Cryptographic Module No further stipulation other than those stated in Method of Activating Private Key This CA s 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. page 41 of 54

42 The activation of the subscriber s private key is controlled by a user or application PIN 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. The CA HSM is operated outside the range of supported temperatures. The HSM detects a security breach and deletes all key material within its internal memory. When private keys are deactivated, they are cleared from memory before the memory is deallocated 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 Cryptographic Module Rating The CA must use an HSM certified to FIPS Level 3 or ISO Common Criteria (CC) EAL 4+ or above. 6.3 Other Aspects of Key Pair Management Public Key Archival Refer to section 5.5 of this CPS 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 five (5) years. Key Certificate type Certification Authority Certificate and associated keys Subscribers Certificates and associated keys Maximum Validity Period Recommended 96 months, re-key at 37% lifetime i.e. 36 months Maximum operational period for a subscriber s key pair must be five years i.e. 60 months. page 42 of 54

43 6.4 Activation Data Activation Data Generation and Installation Activation data is generated by the PKI software and is evaluated as truly random. This data is used to verify the authenticity of certificates generated and signed by this CA before it is installed and activated Activation Data Protection Activation data is generated by this CA for every certificate enrollment 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 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 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. page 43 of 54

44 6.6 Life Cycle Technical Controls 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 vendor Security Management Controls This CA s system is dedicated and tightly controlled with respect to access to it. 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 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 44 of 54

45 7 CERTIFICATE, CRL PROFILES 7.1 Certificate Profile Version Number This CA issues X.509 version 3 certificates as defined in RFC Certificate Extensions Subscribers certificates require the use of the following extensions: KeyUsage (not critical) AuthorityKeyId (not critical) AuthorityInformationAccess(not critical) CP(not critical) CDP(not critical) OCSP response signing certificates require the use of the following extensions: KeyUsage (not critical) AuthorityKeyId (not critical) Extended KeyUsage (critical) OCSPNoCheck (not critical) Algorithm Object Identifiers X.509v3 standard OIDs is used. Algorithm must be RSAencryption for the subjectkey and SHA256withRSA encryption for the certificate signature Name Forms As per the naming conventions and constraints listed in section 3.1 of this CPS Name Constraints As per the naming conventions and constraints listed in section 3.1 of this CPS Certificate Policy Object Identifier Refer to the ASN1 definitions described in the below subsections Usage of Policy Constraints Extension No stipulation Policy Qualifiers Syntax and Semantics No stipulation. page 45 of 54

46 7.1.9 Processing Semantics for Critical Certificate Extensions Critical extensions, when marked, is interpreted by relying parties accordingly Subscriber s Encryption Certificate ASN1 Description This is the complete ASN1 description of the certificate associated to the Encryption key of the subscriber. Object Format Certificate Content Certificate Sequence TbsCertificate Sequence Version Integer 2 (Version 3) SerialNumber Integer Generated Unique by the CA Signature OID Sha-256WithRSAencryption Issuer UTF8 {CN=Business and Corporate Certification Authority, O=QECC, C=QA} Validity UTC-Time NotBefore: <<creation date>> Subject PRINTABLE STRING NotAfter: <<creation date + n years>> n: 5 years for citizen, 3 years for residents As per section SubjectPublicKeyInfo Sequence AlgorithmIdentifier OID RSAencryption (Parameter = NULL) SubjectPublicKey BitString Public key (256 bytes) + exp. pub. Extensions Sequence AuthorityKeyId OctString <<SHA1 of subjectpublickey of Issuer (Business and Corporate CA certificate>> Critical Boolean False KeyUsage BitString 20 : Key Encipherment Critical Boolean False AIA Sequence accessmethod OID Certification Authority Issuer ( ) accesslocation IA5String Cert file name].crt accessmethod OID OCSP( ) accesslocation IA5String Certificate policy Sequence PolicyInformation Sequence policyidentifier OID policyidentifier OID Critical Boolean False CDP Sequence page 46 of 54

47 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 PCA private key>> (512 octets) Subscriber s Signing Certificate ASN1 Description This is the complete ASN1 description of the certificate associated to the signing key of the subscriber. Object Format Certificate Content Certificate Sequence TbsCertificate Sequence Version Integer 2 (Version 3) SerialNumber Integer Generated Unique by the CA Signature OID Sha-256WithRSAencryption Issuer UTF8 { CN= Citizen and Resident Certification Authority, O = qecc, C = qa} Validity UTC-Time NotBefore: <<creation date>> NotAfter: <<creation date + n years>> n: 5 years for citizen, 3 years for residents Subject PRINTABLE As per section STRING SubjectPublicKeyInfo Sequence AlgorithmIdentifier OID RSAencryption (Parameter = NULL) SubjectPublicKey BitString Public key (256 bytes) + exp. pub. Extensions Sequence AuthorityKeyId OctString <<SHA1 of subjectpublickey of Issuer (Business and Corporate CA certificate>> Critical Boolean False KeyUsage BitString 80 : digital signature Critical Boolean False AIA Sequence accessmethod OID Certification Authority Issuer ( ) accesslocation IA5String Cert file name].crt page 47 of 54

48 accessmethod OID OCSP( ) accesslocation IA5String Certificate policy Sequence PolicyInformation Sequence policyidentifier OID policyidentifier OID Critical Boolean False 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 PCA private key>> (512 octets) 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 extendedkeyusage 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=Citizen and Resident Certification Authority, O=QECC, C=QA} Validity UTC-Time NotBefore: <<creation date>> NotAfter: <<creation date +3 Years>> Subject UTF8 { CN=MoI OCSP, CN=Citizen and Resident Certification Authority, O=QECC, C=QA} page 48 of 54

49 SubjectPublicKeyInfo Sequence AlgorithmIdentifier OID RSAencryption (Parameter = NULL) SubjectPublicKey BitString Public key (256 bytes) + exp. pub. Extensions Sequence AuthorityKeyId OctString <<SHA1 of subjectpublickey of Issuer (Business and Corporate CA certificate>> Critical Boolean False KeyUsage BitString C0 : digital signature and non-repudiation Critical Boolean False ExtendedKeyUsage OctString OCSP Signing ( ) Critical Boolean True OCSPNoCheck OctString NULL Critical Boolean False SignatureAlgorithm OID Sha-256WithRSAencryption SignatureValue BitString <<signed using the infrastructure private key>> (512 octets) 7.2 CRL Profile The version field in the certificate states 1, indicating X.509v2 CRL Version Number(s) The version field in the certificate states 1, indicating X.509v2 CRL CRL and CRL Entry Extensions The CRL extensions contain the CRLNumber (a sequential number incremented with each new CRL produced) CRL ASN1 Description Object Format Certificate Content CertificateList Sequence TbsCertList Sequence Version Integer 1 (Version 2) Signature OID Sha-256WithRSAencryption Issuer UTF8 { CN=Citizen and Resident 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 page 49 of 54

50 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 octets) page 50 of 54

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

52 9 OTHER BUSINESS AND LEGAL MATTERS 9.1 Fees Certificate issuance or renewal fees Fees details will be provided at the time of certificate issuance Certificate access fees No fees associated with access to revocation and status information Revocation or status information access fees No fees associated with access to revocation and status information Fees for other services No stipulation - this section intentionally left blank 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 Scope of confidential information All the information that is not explicitly mentioned under section 2.2 is deemed as Confidential/Private Information 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 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. page 52 of 54

53 9.4 Privacy of personal information 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) Term and termination No stipulation - this section intentionally left blank Individual notices and communications with participants No stipulation - this section intentionally left blank. page 53 of 54

54 9.12 Amendments No stipulation - this section intentionally left blank Dispute resolution provisions No stipulation - this section intentionally left blank Governing Law The CA shall operate within the state of Qatar legal jurisdiction Compliance with applicable law No stipulation - this section intentionally left blank Miscellaneous provisions Entire agreement No stipulation - this section intentionally left blank Assignment No stipulation - this section intentionally left blank 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 Enforcement (attorneys' fees and waiver of rights) No stipulation - this section intentionally left blank Force Majeure No stipulation - this section intentionally left blank Other provisions No stipulation - this section intentionally left blank. page 54 of 54