PKI Belgium Government CA Government AA Certification Practice Statement 2.16.56.1.1.1.3 2.16.56.1.1.1.3.2 2.16.56.1.1.1.3.3 2.16.56.1.1.1.3.4 2.16.56.1.1.1.6 2.16.56.1.1.1.6.2 2.16.56.9.1.1.3 2.16.56.9.1.1.3.2 2.16.56.9.1.1.3.3 2.16.56.9.1.1.3.4 2.16.56.9.1.1.6 2.16.56.9.1.1.6.2 2 Government CA - Government AA Certification Practice Statement 1 / 54
Contents 1. Document History...5 1.1 Document Approval...5 1.2 Distribution List...5 1.3 Document Change Control...5 2. Acknowledgments...6 3. Introduction...7 3.1 Overview...7 3.2 eid hierarchy...8 3.3 Document Name and Identification... 11 3.4 PKI participants... 11 3.4.1 Certification Authority...11 3.4.2 Registration Authorities and Local Registration Authorities...12 3.4.3 Subscribers...12 3.4.4 Relying Parties...13 3.5 Certificate usage... 13 3.6 Policy Administration... 13 3.7 Definitions and acronyms... 13 4. Publication and Repository Responsibilities... 13 4.1 Access control on repositories... 14 5. Identification and Authentication... 14 5.1 Naming... 15 5.2 Identity Validation... 15 5.3 Identification and Authentication for Re-key Requests... 15 5.4 Identification and Authentication for Revocation and Suspension Requests... 15 6. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS... 15 6.1 Certificate Application... 16 6.2 Certificate Application Processing... 16 6.3 Certificate Issuance... 16 6.4 Certificate Acceptance... 16 6.5 Key Pair and Certificate Usage... 16 6.5.1 Subscriber duties...17 6.5.2 Relying party duties...17 6.6 Certificate Renewal... 17 6.7 Certificate Re-key... 18 6.8 Certificate Modification... 18 6.9 Certificate Revocation and Suspension... 19 6.9.1 Term and Termination of Suspension and Revocation...19 6.10 Certificate Status Services... 20 6.11 End of Subscription... 20 6.12 Key Escrow and Recovery... 20 7. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS... 21 7.1 Physical Security Controls... 21 7.2 Procedural Controls... 21 7.3 Personnel Security Controls... 22 7.3.1 Qualifications, Experience, Clearances...22 7.3.2 Background Checks and Clearance Procedures...22 7.3.3 Training Requirements and Procedures...22 7.3.4 Retraining Period and Retraining Procedures...22 7.3.5 Job Rotation...23 7.3.6 Sanctions against Personnel...23 7.3.7 Controls of independent contractors...23 7.3.8 Documentation for initial training and retraining...23 7.4 Audit Logging Procedures... 23 7.5 Records Archival... 25 2 Government CA - Government AA Certification Practice Statement 2 / 54
7.5.1 Types of records...25 7.5.2 Retention period...25 7.5.3 Protection of archive...25 7.5.4 Archive backup procedures...25 7.5.5 Requirements for Time-stamping of Records...25 7.5.6 Archive Collection...25 7.5.7 Procedures to obtain and verify archive information...25 7.6 Key Changeover... 26 7.7 Compromise and Disaster Recovery... 26 7.8 CA or RA Termination... 26 8. TECHNICAL SECURITY CONTROLS... 27 8.1 Key Pair Generation and Installation... 27 8.1.1 CA Private Key Generation Process...27 8.1.2 CA Key Generation...27 8.2 Key Pair re-generation and re-installation... 28 8.2.1 CA Key Generation Devices...28 8.2.2 CA Private Key Storage...28 8.2.3 CA Private Key Distribution...29 8.2.4 CA Private Key Destruction...29 8.3 Private Key Protection and Cryptographic Module Engineering Controls... 29 8.4 Other Aspects of Key Pair Management... 30 8.4.1 Computing resources, software, and/or data corrupted...30 8.4.2 CA public key revocation...30 8.4.3 Compromise of the GCA-AA private key...30 8.5 Activation Data... 30 8.6 Computer Security Controls... 30 8.7 Life Cycle Security Controls... 31 8.8 Network Security Controls... 31 8.9 Time-stamping... 31 9. CERTIFICATE AND CRL PROFILES... 32 9.1 Certificate Profile... 32 9.1.1 Government CA Cerificate...32 9.1.2 Government AA Cerificate...38 9.2 Certificate Revocation List (CRL) Profile... 41 10. COMPLIANCE AUDIT AND OTHER ASSESSMENT... 43 11. OTHER BUSINESS AND LEGAL MATTERS... 44 11.1 Fees... 44 11.1.1 Refund policy...44 11.2 Financial Responsibility... 44 11.3 Liability... 44 11.4 Confidentiality of Information... 45 11.4.1 Disclosure Conditions...45 11.4.2 Privacy of Personal Information...46 11.4.3 Intellectual Property Rights...46 11.5 Representations and Warranties... 46 11.5.1 Subscriber Obligations...46 11.5.2 Relying Party Obligations...47 11.5.3 Subscriber Liability towards Relying Parties...47 11.5.4 CA Repository and Web site Conditions of Use...47 11.5.5 GCA-AA Obligations...48 11.5.6 Service Level Measurement...49 11.5.7 Registration Authority Obligations...49 11.6 Disclaimers of Warranties... 49 11.6.1 Limitation for Other Warranties...49 11.6.2 Exclusion of Certain Elements of Damages...49 11.7 Indemnities... 50 2 Government CA - Government AA Certification Practice Statement 3 / 54
11.8 Term and Termination... 50 11.9 Individual notices and communications with participants... 50 11.10 Survival... 50 11.11 Severability... 50 11.12 Amendments... 50 11.13 Dispute Resolution Procedures... 51 11.14 Governing Law... 51 11.15 Miscellaneous Provisions... 51 12. List of definitions... 52 13. List of acronyms... 54 2 Government CA - Government AA Certification Practice Statement 4 / 54
1. Document History 1.1 Document Approval Name + Title Date Signature Checked by: Fedict Approved by Fedict 19 januari 2012 1.2 Distribution List Version Company Name Action V1.0 Fedict Samoera Jacobs Fedict Sam Van Den Eynde 1.3 Document Change Control Version Release Date Status + Description V0.1 04 March 03 First draft V0.1.1 21 March 03 Update after comparison with the CPS for the Admin CA V0.1.2 12 October 2004 Update V0.2 Update regarding BRCA2 Introduction Gov AA V1.0 19 januari 2012 Update, minor corrections 2 Government CA - Government AA Certification Practice Statement 5 / 54
2. Acknowledgments This Government CA - AA 1 CPS 2 describes certification practices for digital certificates issued for the Belgian government applications or government platforms. These certification practices are compliant with the following standards: RFC 2527: Internet X.509 Public Key Infrastructure _ Certificate Policies and Certification Practices Framework, RFC 3280: Internet X.509 Public Key Infrastructure - Certificate and CRL Profile. RFC 2560: X.509 Internet Public Key Infrastructure - Online Certificate Status Protocol - OCSP ETSI TS 101 042: Policy requirements for certification authorities issuing public key certificates (Normalised level only). The ISO 1-7799 standard on security and infrastructure. 1 CA = Certification Authority 2 Certification Practice Statement 2 Government CA - Government AA Certification Practice Statement 6 / 54
3. Introduction This Certification Practice Statement (hereinafter, CPS) of the Government CA and Government AA (hereinafter, the GCA-AA) applies to all certification services provided in the context of the GCA-AA. Together with this CPS other documents may have to be taken into account. These documents will be available through the CA repository at: http://repository.pki.belgium.be. This CPS complies with the formal requirements of Internet Engineering Task Force (IETF) RFC 2527, version 12 July 2001 with regard to format and content. While certain section titles are included according to the structure of RFC 2527, the topic may not necessarily apply in the implementation of the certification services of the GCA-AA. Such sections are denoted as Section not applicable. Minor editorial changes of RFC 2527 prescriptions have been inserted in this CPS to better adapt the structure of RFC 2527 to the needs of this application domain. The CPS addresses in detail the technical, procedural and organisational policies and practices of the GCA-AA with regard to all certification services it provides and during the complete lifetime of certificates issued by the GCA-AA Further information with regard to this CPS and the GCA-AA can be obtained from the GCA-AA itself in the following address, attn. Fedict, Legal Practices, Rue Marie-Thérèse 1-3 B-1000 Brussels, BELGIUM. Important note regarding the Belgium Root PKI infrastructure Starting from 2008 an additional Belgium Root Certification Authority (BRCA) has been introduced in the eid PKI environment. This Belgium Root Certification Authority2 (BRCA2) is necessary in order to continue to issue certificates after 26th of October 2008. As of this date it is impossible to issue certificates under the initial BRCA. This CPS is applicable for Government CA & Government AA under both BRCA s. References to the BRCA in this document are applicable to both BRCA s unless clearly stated. In order to overcome any misunderstanding regarding which BRCA is referred to, the following convention is used: When referring to the first BRCA it will be describe as BRCA(1), the number 1 is set between brackets as the real name of this BRCA does not contain the number 1. When referring in this document to the second BRCA it will be describe as BRCA2. With the introduction of the BRCA2 a new set of OID numbers is used to clearly identify the difference between the BRCA(1) and BRCA2. For technical details regarding the BRCA certificates we refer to CHAPTER 7. CERTIFICATE AND CRL PROFILES in CPS of the Belgium ROOT CA. This can be found at http://repository.pki.belgium.be 3.1 Overview A certification practice statement (CPS) is a unilateral declaration of the practices that a Certification Authority complies with when it provides certification services. A CPS is a comprehensive description 2 Government CA - Government AA Certification Practice Statement 7 / 54
of how the CA makes its services available. This CPS is intended to be used within the CA domain 3 to the exclusion of any other. The CPS aims at delimiting the GCA-AA domain of providing certification services to entities within the governmental context. This CPS also outlines the relationship between the Government Certification Authority (GCA-AA) and other CAs within the Belgian Government PKI hierarchy such as the Belgium Root Certification Authority (BRCA) 4. It also describes the relationship between the Government CA and the other organisations involved in the delivery of the certificates for the Belgian Electronic Identity Cards Infrastructure. The organisation issuing certificates is called Certification Authority (CA), the organisation in charge of the identification of the person applying for a certificate is called Registration Authorities (RA). The role of the RA can be delegated to a LRA. Although the function of the issuer of the certificates and the registration authority coincide on the same entity within the Belgian Public Administration, from a systematic viewpoint they both fulfil different roles to meet different requirements. For example, only the RA and the LRA can request the GCA-AA to issue a certificate. This CPS also provides operational guidelines for all the civil servants responsible for the infrastructure of the Belgian Electronic ID cards. This CPS provides operational guidelines to other CAs, such as the BRCA, that belong to the PKI hierarchy of the Belgian State within the legal framework for electronic signatures and electronic identity cards in Belgium. This CPS describes the relationships between the GCA-AA and all other entities that retain an organisational link with the GCA-AA such as suppliers of services. The Belgian State acquires these services through appropriate agreements concluded with these third party suppliers. Finally in an accreditation and supervisory perspective this CPS provides guidance to supervising authorities, accreditation bodies, accredited auditors etc with regard to the practices. This CPS is made available on-line in the Repository of the issuing CA under http://repository.eid.belgium.be. The GCA-AA accepts comments regarding this CPS addressed to: servicedesk@fedict.be or by post to, attn. Fedict, Legal Practices, Rue Marie-Thérèse 1-3 B-1000 Brussels BELGIUM. 3.2 eid hierarchy To use the Belgian eid card to its full extent, it is required to ensure both the citizen s identity and the identity of the Belgian State technical infrastructure and applications. It is, therefore, required to use multiple types of certificates beyond the eid citizen certificates. The GCA-AA belongs to a broader domain of CAs of the Belgian State. To facilitate the building of trust among the various participating CAs, the Belgian State has set up a CA hierarchy. In this hierarchy, there is a Belgium Root CA (BRCA) that has as purpose amongst others to build trust in the various CAs within the government domain. The BRCA has certified each of the private keys of the CAs in the government domain including the GCA-AA. By validating the certificate of such a CA, the trust in the BRCA can also be applied to the CA it has certified. To the extent that the BRCA is trusted, a certificate issued by the GCA-AA can be trusted as well. Trust in BRCA within software applications is also ascertained through root sign carried out by a third party provider, whose root has widely been embedded in application software. The BRCA operates under practices published in a dedicated CPS available at http://repository.pki.belgium.be. 3 The CA domain is the area of competence of the CA to provide certification services. This means the CA domain does for instance not include the applications using the certificates, etc. 4 The BRCA is the CA that has certified the Government CA. Trust in the BRCA, automatically implies that verification of the certificate of the Government CA may take place, hence resulting implicitly in trusting the Government CA. 2 Government CA - Government AA Certification Practice Statement 8 / 54
Trust in the certificates issued by the GCA-AA can be verified as follows: 1. Trusted path building. The certificate is checked on whether it has been issued by the GCA-AA. Pursuant to that, the GCA-AA certificate is checked on whether it has been indeed issued by the BRCA. When the result of these controls is positive Trust from the BRCA can be cascaded via the GCA-AA certificate to the end entity certificate. 2. Verification of the BRCA certificate. Generally the BRCA certificate is indicated in the application s certificate store as a trusted certificate. In the unlikely case that an end user is warned that the BRCA certificate is not valid anymore, it is sufficient that the end user removes the BRCA certificate from the certificate store to exclude that domain from its trusted ones to ascertain that this part of the verification fails. 3. Verification of the GCA-AA certificate can be ascertained by taking the following steps: 3.1. Check of the validity of the GCA-AA certificate (e.g. check expiration date) 3.2. Check of the status of the GCA-AA certificate (e.g. check the suspension or revocation state). 4. Verification of the end entity certificate can be ascertained by taking the following steps: 4.1. Check of the validity of the end entity certificate (e.g. check that its validity period is not expired). 4.2. Check of the status of the end entity certificate (e.g. check the suspension or revocation state). Generally most or all of these operations are performed automatically by the application that uses the certificates requiring minimal or no end user interaction. The Trust hierarchy of the certificates follows 1. A small hierarchy for which all the required information to validate the eid citizen certificates offline can be stored in the card. 2. A high preference for automated trust in certificates issued by the Belgian State infrastructure without requiring end-user intervention, which allows, however, online verification. This more complex hierarchy is described in figure 1 below: 2 Government CA - Government AA Certification Practice Statement 9 / 54
Figure 1: Government CA & AA hierarchy To meet both requirements, the Government CA hierarchy consists of a combination of a two-layered and a three-layered model. The two-layer model is used for the validation of the eid citizen certificates in an off-line mode not further relevant for the GCA-AA. In the two-layered model the eid Citizen CA and the Self-Signed Belgium Root CA 5 form a hierarchy, which in an off-line mode allows validating the eid Citizen signing and authentication certificates. In the three-layered model the GCA-AA, is signed by the Belgium Root CA (BRCA) which is signed by the GlobalSign Top Root CA form a CA hierarchy. This approach allows the automated validation within the most widely used applications, e.g. browsers; because these browsers have already embedded the GlobalSign Top Root CA certificate and they list it as a trusted one. Just as the GCA- AA inherits trust from the BRCA, the BRCA inherits trust from the GlobalSign Top Root CA. This threelayered model eliminates the need to individually import the Self-Signed Belgium Root CA certificate. Because both the Self-Signed Belgium Root CA and the Belgium root signed Root CA share the same key pair albeit using two different certificates, a certificate signed by the private key of that key pair can be validated with both Belgium Root certificates. In most case the application builder will have foreseen one of both models to be used, and the end user will not have to choose between the two models. 5 A self-signed certificate is a certificate signed with the private key of the certified entity itself. Since there is no trust point higher above in the Trust hierarchy, no trust can be build on that certificate or any of the certificates that are lower in the hierarchy if that self-signed certificate is not trusted. This, however, is a case that very rarely might occur. 2 Government CA - Government AA Certification Practice Statement 10 / 54
3.3 Document Name and Identification This CPS can also be identified by any party through the following OIDs 6 : Certificate Type OID Belgium Root CA (1) PKI BRCA(1) Government CA certificate 2.16.56.1.1.1.3 Server Certificate 2.16.56.1.1.1.3.2 Applications Certificate 2.16.56.1.1.1.3.3 Persons certificate 2.16.56.1.1.1.3.4 Government AA certificate 2.16.56.1.1.1.6 Identity Provider Certificate 2.16.56.1.1.1.6.2 Belgium Root CA 2 PKI - BRCA2 Government CA certificate 2.16.56.9.1.1.3 Server Certificate 2.16.56.9.1.1.3.2 Applications Certificate 2.16.56.9.1.1.3.3 Persons certificate 2.16.56.9.1.1.3.4 Government AA certificate 2.16.56.9.1.1.6 Identity Provider Certificate 2.16.56.9.1.1.6.2 3.4 PKI participants Several parties make up the participants of this PKI hierarchy. The parties mentioned hereunder including all CAs, the RAs, LRAs, the subscribers and relying parties are collectively called PKI participants. 3.4.1 Certification Authority A Certification Authority is an organisation that issues digital certificates. In the GCA-AA domain, Belgian federal government acts as the CA also called in this CPS GCA-AA. The actual certification operations including issuance, certificates status, and repository services are delegated to private contractual parties operating on behalf of the Belgian State. These parties carrying out services on behalf of the GCA-AA are mentioned hereinafter as the GCA-AA operator. The GCA-AA operator operates within a grant of authority for issuing GCA-AA end-entity certificates. This grant has been provided by the Belgium Root Certification Authority (BRCA). The GCA-AA ensures the availability of all services pertaining to the certificates, including the issuing, revocation, status verification, as they may become available or required in specific applications. The GCA-AA is established in Belgium. It can be contacted at the address published elsewhere in this CPS. To deliver CA services including the issuance, suspension, revocation, renewal, status verification of certificates, the CA operates a secure facility and provides for a disaster recovery facility in Belgium. In specific the CA s domain of responsibility comprises the overall management of the certificate lifecycle including: 1. Issuance 2. Suspension/Unsuspension 6 Object Identifier 2 Government CA - Government AA Certification Practice Statement 11 / 54
3. Revocation 4. Status verification (Certificate Status Service) 5. Directory service 3.4.1.1 The root sign provider The root sign provider ensures Trust in BRCA in widely used applications. The root sign provider ensures that its root remains trusted by such applications and notifies PKI participants of any event affecting Trust to its own root. 3.4.2 Registration Authorities and Local Registration Authorities Belgian Federal Government is the Registration Authority (RA) within the GCA-AA domain. The RA may decide upon the issuance, suspension and revocation of a certificate under this CPS. The RA may appoint a third party to further carry out RA tasks within the GCA-AA domain. This third party is called a Local Registration Authority (LRA). The RA submits the necessary data for the generation and revocation of the certificates to the GCA- AA operator. The RA registers and verifies the subscriber data and the identity of the subscriber. The RA interacts indirectly with the subscriber and directly with the GCA-AA to deliver PKI services. In specific, the RA: Validate the identity of the subscriber during the certificate issuance procedure. Follow the procedures to complete the registration file, including the electronic PKCS#10 certificate request. Validate the registration file and requesting the GCA-AA to issue a certificate based on the electronic PKCS#10 request. Initiate the process to issue a certificate and request a certificate revocation from the GCA-AA Deliver the certificates to the subscriber. The RA supplies the GCA-AA with the necessary data to enable it construct the certificates. For each certificate the RA supplies the PKCS#10 requests including the public key as generated by the subscriber. All communications between the LRA, RA, GCA-AA and GCA-AA operator regarding any phase of the life cycle of certificates is secured with PKI based encryption and signing techniques, to ensure confidentiality and mutual authentication. This includes communications containing certificate requests, issuance, suspension, un-suspension and revocation. 3.4.3 Subscribers The Subscribers of the CA services in the GCA-AA domain are entities including natural or legal persons in a governmental context whose identity and public key are certified in the certificates. In case of a legal person, the requester is normally a legal representative of the requesting organisation or department. The Subscribers: : Are identified Hold the private keys corresponding to the respective public keys that are listed in their respective certificates. 2 Government CA - Government AA Certification Practice Statement 12 / 54
3.4.4 Relying Parties Relying parties are entities including natural or legal persons that rely on a certificate and/or a digital signature verifiable with reference to a public key listed in the certificate. To verify the validity of a digital certificate they receive, relying parties must always verify with a CA Validation Service (e.g. OCSP, CRL, delta CRL, web interface) prior to relying on information featured in a certificate. 3.5 Certificate usage Certain limitations apply to the usage of the GCA-AA end-entity certificates. The SSL Server certificates are used for server authentication and encryption only. The applications on these servers can be used for public available services towards organisations, citizens or professionals or to secure the communication with the different government servers and/or platforms. Application Certificate can be used for object signing for Belgian Government applications. The Person certificate is a non-repudiation certificate used by natural or legal person interacting with Belgian Government applications for data signing and data encryption. The Identifier certificate is used for SAML responder in Belgian Government applications. 3.6 Policy Administration Policy administration is reserved to the RA. Policy Administration can be contacted in the following address: attn. Fedict, Legal Practices, Rue Marie-Thérèse 1-3 B-1000 Brussels BELGIUM. 3.7 Definitions and acronyms Lists of definitions and acronyms can be found at the end of this CPS. 4. Publication and Repository Responsibilities The GCA-AA publishes information about the digital certificates it issues in (an) online publicly accessible repository (ies) under the Belgian Internet Domain. The GCA-AA retains an online repository of documents where it makes certain disclosures about its practices, procedures and the content of certain of its policies including its CPS, which will be accessible at http://repository.pki.belgium.be. The GCA-AA reserves its right to make available and publish information on its policies by any means it sees fit. PKI participants are notified that the GCA-AA may publish information they submit directly or indirectly to the GCA-AA on publicly accessible directories for purposes associated with the provision of electronic certificate status information. The GCA-AA publishes digital certificate status information in frequent intervals as indicated in this CPS. The GCA-AA sets up and maintains a repository of all certificates it has issued. This repository also indicates the status of a certificate issued. 2 Government CA - Government AA Certification Practice Statement 13 / 54
The GCA-AA publishes CRLs 7 at regular intervals at http://crl.pki.belgium.be/. The GCA-AA publishes delta CRLs containing any changes since the publication of the previous CRL or delta CRL, at regular intervals. Any newly published CRL includes all updates of the delta CRLs, published until then. The GCA-AA makes available an OCSP 8 server at http://ocsp. pki.belgium.be that provides notice on the status of a certificate, issued by the GCA-AA upon request from a relying party, in compliance with IETF RFC 2560. The status of any certificate listed in a CRL or delta CRL, must be consistent with the information, delivered by the OCSP server. The GCA-AA maintains the CRL distribution point and the information on this URL until the expiration date of all certificates, containing the CRL distribution point. Approved versions of documents to be published on the Repository are uploaded within 24 hours. Due to their sensitivity the GCA-AA refrains from making publicly available certain subcomponents and elements of such documents including certain security controls, procedures related with the functioning of inter alia registration authorities, internal security polices etc. Such documents and documented practices are, however, conditionally available to audit to designated parties that the GCA-AA owes duty to. 4.1 Access control on repositories The OCSP service, web interface certificate status verification service, the certificate repository and the CRLs and delta CRLs are publicly available via the Internet. Access restrictions to any of these services include: The RA may exclusively issue general queries on the certificate repository, whereby sets of certificates are delivered as a result of the query. Through the publicly available interface to the certificate repository, only a single certificate can be delivered per query made by any party except of the RA. The CA may take reasonable measures to protect against abuse of the OCSP, Web interface status verification and CRL and delta CRL download services. In particular: The CA may restrict the processing frequency of OCSP requests by a single user to 10 requests per day if the CA can demonstrate that the user is abusing the system. The CA may restrict the processing frequency of Web interface certificate status verification requests by a single user to 10 requests per day. The CA may restrict the successful downloading of a CRL once per week or delta CRL by a single user to 8 per day. 5. Identification and Authentication The RA maintains documented practices and procedures to authenticate the identity and/or other attributes of a certificate applicant. Prior to requesting the issuance of a certificate the RA verifies the identity of the certificate applicant that wants to request a certificate under the Government CA. The RA authenticates the requests of parties wishing the revocation of certificates under this policy. 7 A CRL or Certificate Revocation List is a list issued and digitally signed by a CA that includes revoked and suspended certificates. Such list is to be consulted by relying parties at all times prior to relying on information featured in a certificate. 8 The Online Certificate Status Protocol (RFC 2560) is a real time status information resource used to determine the current status of a digital certificate without requiring CRLs 2 Government CA - Government AA Certification Practice Statement 14 / 54
5.1 Naming To identify the CA, the GCA-AA follows certain naming and identification rules that include types of names assigned to the subject, such as X.500 distinguished names RFC-822 names and X.400 names. The GCA-AA does not issue anonymous certificates to subscribers. Names assigned to subscribers of a certificate are unique within the domain of the GCA-AA as they are always used together with a unique sequential number. 5.2 Identity Validation The RA (or LRA) has to verify the identity of the applicant by verifying applicable identity documents. Besides the identity check, the RA (or LRA) has to check if the representative of a legal person is allowed to request certificates. 5.3 Identification and Authentication for Re-key Requests Section not applicable 5.4 Identification and Authentication for Revocation and Suspension Requests Revocation or suspension requires a notification by the subscriber addressed to the RA. Only if the RA is able to verify the identity of the subscriber, the revocation or suspension request gets accepted. Subsequently, the RA forwards promptly all revocation and suspension requests directly to the CA. The RA is the single contact point for the CA to obtain a revocation request. The RA can also based on its own judgement request the suspension or revocation of certificates (e.g. because the information featured in a certificate became invalid and a new certificate will replace the existing one, because the RA has received irrefutable proof of a compromise of the related private key, ). For the identification and authentication procedures of suspension or revocation requests for its subject types the GCA-AA accepts suspension and revocation requests from the RA. Such a request will use dedicated electronic authentication mechanisms. 6. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS For all entities within the GCA-AA domain including the LRAs, subscribers, relying parties and/or other participants there is a continuous obligation to inform directly or indirectly the RA of all changes in the information featured in a certificate during the operational period of such certificate or of any other fact that materially affects the validity of a certificate. The RA will then take appropriate measures to make sure that the situation is rectified (e.g. ask the GCA-AA for the revocation of the existing certificates and the generation of new certificates with the correct data). 2 Government CA - Government AA Certification Practice Statement 15 / 54
The GCA-AA issues, revokes or suspends certificates only at the request of the RA to the exclusion of any other, unless explicitly instructed so by the RA. 6.1 Certificate Application The enrolment process for the end entity certificates is an integral part of the Certificate Policy. 6.2 Certificate Application Processing The RA acts upon a certificate application to validate an applicant s identity as foreseen in the Certificate Policy. The procedures for the validation of an applicant s identity are addressed in the Certificate Policy. Following a certificate application the RA either approves or rejects certificate application. This validation of the applicant s identity can also be delegated to a LRA. If the application is approved the LRA transmits the registration data to the RA. The RA on its own turn either approves or rejects the application. 6.3 Certificate Issuance Following approval of the certificate application the RA sends a certificate issuance request to the GCA-AA. The GCA-AA does not verify the completeness, integrity and uniqueness of the data, presented by the RA, but relies completely on the RA for the correctness of all data. The GCA-AA will generate a unique serial number for the certificate. All requests from the RA are granted approval provided that: They are validly formatted. Use the proper secure communication channel. The GCA-AA verifies the identity of the RA on the basis of credentials presented. The GCA-AA ensures that the issued certificate contains all data that was presented to it in the request of the RA. Following issuance of a certificate, the GCA-AA posts an issued certificate on a Repository. The certificate is thereafter delivered to the subscriber. 6.4 Certificate Acceptance The GCA-AA ensures the data in the certificate are equal to the data in the PKCS#10 request, the Subscriber checks the correctness of the data after receipt of the certificate. The certificate is deemed accepted if no objection is made. 6.5 Key Pair and Certificate Usage The responsibilities relating to the use of keys and certificates include the ones addressed below. 2 Government CA - Government AA Certification Practice Statement 16 / 54
6.5.1 Subscriber duties Unless otherwise stated in this CPS, subscriber s duties include the ones below: Having knowledge of and, if necessary, seeking training on using digital certificates and PKI. Reading, understanding and agreeing with all terms and conditions in this CPS and associated policies published in the Repository. Refraining from tampering with a certificate. Only using certificates for legal and authorised purposes in accordance with the CPS. Notifying the RA of any changes in the information submitted. Ceasing to use a certificate if any featured information becomes invalid. Ceasing to use a certificate when it becomes invalid. When invalid, remove administration certificates, from any applications and/or devices they have been installed on. Refraining from using the public key certified in an administration certificate to have it certified again in another certificate. Using a certificate, as it may be reasonable under the circumstances. Preventing the compromise, loss, disclosure, modification, or otherwise unauthorised use of their private key. Request the suspension of a certificate in case of the suspicion of an occurrence that materially affects the integrity of a certificate. Such suspicions include indications of loss, theft, modification, unauthorised disclosure, or other compromise of the private key of the certificate s subject. Request the revocation of a certificate in case of an occurrence that materially affects the integrity of a certificate. Such occurrences include loss, theft, modification, unauthorised disclosure, or other compromise of the private key of the certificate s subject. Obligation to use the key pair for described usage and in accordance with any other limitations notified to the subscriber; Obligation to exercise reasonable care to avoid unauthorised use of the subscriber s private key; Following compromise, the obligation to immediately and permanently discontinue the use of the subject's private key. Obligation to notify without any reasonable delay in case control over the private key has been lost due to compromise of activation data (e.g. PIN code) 6.5.2 Relying party duties A party relying on a CA certificate will: Have knowledge on using digital certificates and PKI. Receive notice and adhere to the conditions this CPS and associated conditions for relying parties. Validate a certificate by using a CRL, delta CRL, OCSP or web based certificate validation in accordance with the certificate path validation procedure. Trust a certificate only if it has not been suspended or revoked. Rely on a certificate, as may be reasonable under the circumstances. 6.6 Certificate Renewal The subscriber is responsible for requesting a new certificate before the expiration date of the certificate. 2 Government CA - Government AA Certification Practice Statement 17 / 54
6.7 Certificate Re-key This section is not applicable. 6.8 Certificate Modification Section not applicable. 2 Government CA - Government AA Certification Practice Statement 18 / 54
6.9 Certificate Revocation and Suspension Upon request from the RA the GCA-AA suspends or revokes a digital certificate. The RA requests promptly the revocation of a certificate after: Having received notice by the subscriber that there has been a loss, theft, modification, unauthorised disclosure, or other compromise of the private key of the certificate s subject. There has been a modification of the information contained in the certificate of the certificate s subject. The performance of an obligation of the RA under this CPS is delayed or prevented by a natural disaster, computer or communications failure, or other cause beyond the person's reasonable control, and as a result, another person s information is materially threatened or compromised. The GCA-AA revokes a suspended certificate after a period of one week if it does not receive in the meantime notification from the RA to unsuspend the certificate. The CA notifies the RA of all revocations made. Relying parties must use on line resources that the GCA-AA makes available through its repository to check the status of certificates before relying on them. The GCA-AA updates OCSP, the Web interface certification status verification service, CRLs and delta CRLs accordingly. CRLs are updated at each certificate revocation The GCA-AA grants access to OCSP resources and a web site to which status inquiries can be submitted. Relying parties must comply with the GCA-AA policy and in specific with relying party obligations as published in this CPS to be found in the GCA-AA Repository. 6.9.1 Term and Termination of Suspension and Revocation Suspension may last for a maximum of seven calendar days in order to establish the conditions that caused the request for suspension. Following negative evidence of such conditions the subscriber may request to re-activate (unsuspension of) the end entity certificate on the following conditions: The subscriber has ascertained without any doubt that his suspicion that there has been a loss, theft, modification, unauthorised disclosure, or other compromise of the private key of the certificate was incorrect. No other reasons exist to doubt the reliability and confidentiality of the private key of the certificate. To request the unsuspension of the certificate, the subscriber must contact the RA. The RA requests promptly the unsuspension of a certificate after: Having received notice by the subscriber that a suspicion that there has been a loss, theft, modification, unauthorised disclosure, or other compromise of the private key of a end entity certificate was undoubtedly incorrect. The suspicion has proven undoubtedly incorrect that another person s information would be materially threatened or compromised due to the fact that the performance of an obligation of the RA under this CPS was delayed or prevented by a natural disaster, computer or communications failure, or other cause beyond the person's reasonable control. Upon request from the RA the GCA-AA suspends or revokes a end entity certificate. 2 Government CA - Government AA Certification Practice Statement 19 / 54
The GCA-AA automatically revokes a suspended certificate after a period of one week if it does not receive in the meantime notification from the RA to unsuspend the certificate. The GCA-AA notifies the RA of all revocations made. The GCA-AA publishes notices of suspended or revoked certificates in the Repository. 6.10 Certificate Status Services The GCA-AA makes available certificate status checking services including CRLs, delta CRLs, OCSP and appropriate Web interfaces. CRL, delta CRLs A delta CRL lists additions since the publishing of the last base CRL. OCSP CRLs and delta CRLs are signed and time-marked by the GCA-AA. The GCA-AA makes all CRLs and delta CRLs issued in the previous 12 months available on its Website. The OCSP service of the GCA-AA is cascaded with the OCSP service of the BRCA. Web interface for status verification service A simple web interface for status verification services allows a user to obtain status information on a certificate. 6.11 End of Subscription This section is not applicable. 6.12 Key Escrow and Recovery Key escrow and recovery are not allowed. 2 Government CA - Government AA Certification Practice Statement 20 / 54
7. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS This section describes non-technical security controls used by the GCA-AA operator to perform the functions of subject authentication, certificate issuance, certificate revocation, audit, and archival. 7.1 Physical Security Controls The GCA-AA operator implements physical controls on its own premises. The GCA-AA operator s physical controls include the following: The GCA-AA operators secure premises are located in an area appropriate for high-security operations. These premises feature numbered zones and locked rooms, cages, safes, and cabinets. Physical access is restricted by implementing mechanisms to control access from one area of the facility to another or access into high-security zones, such as locating CA operations in a secure computer room physically monitored and supported by security alarms and requiring movement from zone to zone to be accomplished using a token and access control lists. Power and air conditioning operate with a high degree of redundancy. Premises are protected from any water exposures. The GCA-AA operator implements prevention and protection as well as measures against fire exposures. Media are stored securely. Backup media are also stored in a separate location that is physically secure and protected from fire and water damages. To prevent unwanted disclosure of sensitive data waste is disposed of in a secure manner. The GCA-AA operator implements a partial off-site backup. The sites of the GCA-AA operator host the infrastructure to provide the CA services. The GCA-AA operator sites implement proper security controls, including access control, intrusion detection and monitoring. Access to the sites is limited to authorized personnel listed on an access control list, which is subject to audit. Strict access control is enforced to all areas containing highly sensitive material and infrastructure including material and infrastructure pertaining to signing certificates, CRLs and delta CRLs, OCSP and archives. 7.2 Procedural Controls The GCA-AA operator follows personnel and management practices that provide reasonable assurance of the trustworthiness and competence of the members of the staff and of the satisfactory performance of their duties in the fields of electronic signature-related technologies. 2 Government CA - Government AA Certification Practice Statement 21 / 54
The GCA-AA operator obtains a signed statement from each member of the staff on not having conflicting interests with the CA, maintaining confidentiality and protecting personal data. All members of the staff operating the key management operations, administrators, security officers, and system auditors or any other operations that materially affect such operations are considered as serving in a trusted position. The GCA-AA operator conducts an initial investigation of all members of staff who are candidates to serve in trusted roles to make a reasonable attempt to determine their trustworthiness and competence. Where dual control is required at least two trusted members of the GCA-AA staff need to bring their respective and split knowledge in order to be able to proceed with the ongoing operation. The GCA-AA operator ensures that all actions with respect to the GCA-AA can be attributed to the system of the GCA-AA and the member of the GCA-AA staff that has performed the action. For critical GCA-AA functions the GCA-AA implements dual control. The GCA-AA separates among the following discreet work groups: GCA-AA operating personnel that manages operations on certificates. Administrative personnel to operate the platform supporting the GCA-AA. Security personnel to enforce security measures. 7.3 Personnel Security Controls The GCA-AA operator implements certain security controls with regard to the duties and performance of the members of its staff. These security controls are documented in a policy and include the areas below. 7.3.1 Qualifications, Experience, Clearances The GCA-AA operator performs checks to establish the background, qualifications, and experience needed to perform within the competence context of the specific job. Such background checks include: Criminal convictions for serious crimes. Misrepresentations by the candidate. Appropriateness of references. Any clearances as deemed appropriate. 7.3.2 Background Checks and Clearance Procedures The GCA-AA operator makes the relevant checks to prospective employees by means of status reports issued by a competent authority, third-party statements or signed self-declarations. 7.3.3 Training Requirements and Procedures The GCA-AA operator makes available training for their personnel to perform their GCA-AA functions. 7.3.4 Retraining Period and Retraining Procedures Periodic training updates might also be carried out to establish continuity and updates in the knowledge of the personnel and procedures. 2 Government CA - Government AA Certification Practice Statement 22 / 54
7.3.5 Job Rotation This section is not applicable. 7.3.6 Sanctions against Personnel The GCA-AA operator sanctions personnel for unauthorized actions, unauthorized use of authority and unauthorized use of systems for the purpose of imposing accountability on the GCA-AA operator personnel, as it might be appropriate under the circumstances. 7.3.7 Controls of independent contractors Independent GCA-AA operator subcontractors and their personnel are subject to the same background checks as the GCA-AA operator personnel. The background checks include: Criminal convictions for serious crimes. Misrepresentations by the candidate. Appropriateness of references. Any clearances as deemed appropriate. Privacy protection. Confidentiality conditions. 7.3.8 Documentation for initial training and retraining The GCA-AA operator makes available documentation to personnel, during initial training, retraining, or otherwise. 7.4 Audit Logging Procedures Audit logging procedures include event logging and systems auditing, implemented for the purpose of maintaining a secure environment. The GCA-AA operator implements the following controls: The GCA-AA event logging system records events that include but are not limited to: Issuance of a certificate. Revocation of a certificate. Suspension of a certificate. Publishing of a CRL or delta CRL. The GCA-AA operator audits all event-logging records. Audit trail records contain: The identification of the operation. The data and time of the operation. The identification of the certificate, involved in the operation. The identity of the transaction requestor. In addition, the GCA-AA operator maintains internal logs and audit trails of relevant operational events in the infrastructure, including, but not limited to: Start and stop of servers. Outages and major problems. Physical access of personnel and other persons to sensitive parts of the GCA-AA site. Back-up and restore. Report of disaster recovery tests. Audit inspections. Upgrades and changes to systems, software and infrastructure. 2 Government CA - Government AA Certification Practice Statement 23 / 54
Security intrusions and attempts at intrusion. Other documents that are required for audits include: Infrastructure plans and descriptions. Physical site plans and descriptions. Configuration of hardware and software. Personnel access control lists. The GCA-AA operator ensures that designated personnel reviews log files at regular intervals and detects and reports anomalous events. Log files and audit trails are archived for inspection by the authorized personnel of the GCA-AA, the RA and designated auditors. The log files should be properly protected by an access control mechanism. Log files and audit trails are backed up. Auditing events are not given log notice. Audit logging procedures include event logging and systems auditing, implemented for the purpose of maintaining a secure environment. The RA (LRA if LRA performs the RA tasks) implements the following controls. Audit trail records contain: The identification of the operation. The data and time of the operation. The identification of the certificate, involved in the operation. The identity of the transaction requestor. Other documents that are required for audits include: Configuration of hardware and software. Personnel access control lists. The RA (LRA if LRA performs the RA tasks) ensures that designated personnel reviews log files at regular intervals and detects and reports anomalous events. Log files and audit trails are archived for inspection by the authorized personnel of the LRA. The log files should be properly protected by an access control mechanism. Log files and audit trails are backed up. Auditing events are not given log notice. The RA (LRA if LRA performs the RA tasks) keeps internal records of the following items: Audit trails for a period of a minimum of 30 years on the identification of the certificate applicant Audit trails for a period of a minimum of 30 years on the requests to issue certificates and on the requests for revocation of certificates Audit trails for a period of a minimum of 30 years on the delivery of the certificates to the subscribers The RA (LRA if LRA performs the RA tasks) keeps archives in a retrievable format. The RA (LRA if LRA performs the RA tasks) ensures the integrity of the physical storage media and implements proper copying mechanisms to prevent data loss. Archives are accessible to authorized personnel of the RA (LRA if LRA performs the RA tasks). 2 Government CA - Government AA Certification Practice Statement 24 / 54