Government CA Certification Practice Statement v1.0

2 Government CA - Government AA Certification Practice Statement 1 / 54

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


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


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


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


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

This Government CA - AA1 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


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-Thrse 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 BRCAs. References to the BRCA in this document are applicable to both BRCAs 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
http://repository.pki.belgium.be/http://repository.pki.belgium.be/


of how the CA makes its services available. This CPS is intended to be used within the CA domain3 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: [email protected] or by post to, attn. Fedict, Legal Practices, Rue Marie-Thrse 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 citizens 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.
http://repository.pki.belgium.be/


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

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


Elements present

on the smart card

Administration CA Citizen CAGovernment CA

Belgium Self-

Signed

Root CA

SelfSigned

Common

KeyPair

Role,

Interface...Signing Auth.

SSL

Server,

Object

Signing...

GlobalSign Top Root CA

Belgium RootSigned

Root CA

SelfSigned

AIAAIA

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 three-layered 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.


3.3 Document Name and Identification

This CPS can also be identified by any party through the following OIDs6:

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 CAs domain of responsibility comprises the overall management of the certificate lifecycle including:

1. Issuance 2. Suspension/Unsuspension

6 Object Identifier


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.


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-Thrse 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.
http://repository.pki.belgium.be/


The GCA-AA publishes CRLs7 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
http://crl.pki.belgium.be/


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


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 applicants identity as foreseen in the Certificate Policy. The procedures for the validation of an applicants identity are addressed in the Certificate Policy. Following a certificate application the RA either approves or rejects certificate application. This validation of the applicants 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.


6.5.1 Subscriber duties

Unless otherwise stated in this CPS, subscribers 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 certificates 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 certificates 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 subscribers 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.


6.7 Certificate Re-key

This section is not applicable.

6.8 Certificate Modification

Section not applicable.


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 certificates subject. There has been a modification of the information contained in the certificate of the certificates

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


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

OCSP

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


6.12 Key Escrow and Recovery

Key escrow and recovery are not allowed.


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


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.


7.3.5 Job Rotation


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.


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


7.5 Records Archival

The GCA-AA keeps internal records of the following items:

All certificates for a period of a minimum of 30 years after the expiration of that certificate.

Audit trails on the issuance of certificates for a period of a minimum of 30 years after issuance of a certificate.

Audit trail of the revocation of a certificate for a period of a minimum of 30 years after revocation of a certificate.

CRLs and delta CRLs for a minimum of 30 years after publishing.

The GCA-AA should retain the very last back up of the GCA-AA archive for 30 years following the issuance of the last certificate.

The GCA-AA keeps archives in a retrievable format. The GCA-AA 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 GCA-AA and the RA.

7.5.1 Types of records

The GCA-AA retains in a trustworthy manner records of digital certificates, audit data, GCA-AA systems information and documentation.

7.5.2 Retention period

The GCA-AA retains in a trustworthy manner records of digital certificates for a term as indicated under article 5.5 in this CPS.

7.5.3 Protection of archive

Only the records administrator (member of staff assigned with the records retention duty) may access a GCA-AA archive. Measures are taken to ensure:

Protection against modification of archive, such as storing the data on a write once medium.

Protection against deletion of archive.

Protection against deterioration of the media on which the archive is stored, such as a requirement for data to be migrated periodically to unused media.

7.5.4 Archive backup procedures

A differential back up of the GCA-AA archives is carried out on a daily basis during working days.

7.5.5 Requirements for Time-stamping of Records


7.5.6 Archive Collection

The GCA-AA archive collection system is internal.

7.5.7 Procedures to obtain and verify archive information

Only GCA-AA staff members with a clear hierarchical control and a definite job description may obtain and verify archive information. The GCA-AA retains records in electronic or in paper-based format.


7.6 Key Changeover


7.7 Compromise and Disaster Recovery

In a separate internal document the GCA-AA operator specifies applicable incident, compromise reporting and handling procedures. The GCA-AA operator specifies the recovery procedures used if computing resources, software, and/or data are corrupted or suspected of being corrupted. The GCA-AA operator establishes the necessary measures to ensure full and automatic recovery of the service in case of a disaster, corrupted servers, software or data. A business continuity plan has been implemented to ensure business continuity following a natural or other disaster. All such measures are compliant with ISO 1-7799. The GCA-AA operator establishes:

Disaster recovery resources in dual locations sufficiently distant from each other.

Fast communications between the two sites to ensure data integrity

A communications infrastructure from both sites to the RA supporting Internet communications protocols.

Disaster recovery infrastructure and procedures are tested at least yearly.

7.8 CA or RA Termination



8. TECHNICAL SECURITY CONTROLS

This section defines the security measures the CA takes to protect its cryptographic keys and activation data (e.g., PINs, passwords, or manually-held key shares).

8.1 Key Pair Generation and Installation

The GCA-AA protects its private key(s) in accordance with this CPS. The GCA-AA uses private signing keys only for signing certificates, CRLs, delta CRLs and OCSP responses in accordance with the intended use of each of these keys. The GCA-AA will refrain from using its private keys used within the GCA-AA in any way outside the scope of the GCA-AA domain.

8.1.1 CA Private Key Generation Process

The GCA-AA uses a trustworthy process for the generation of its root private key according to a documented procedure. The GCA-AA distributes the secret shares of its private key(s). The GCA-AA operator acts upon authorisation by the Belgian Government who is the owner of the GCA-AA private keys, to perform cryptographic operations using the GCA-AA private key(s). The GCA-AA has the authority to transfer such secret shares to authorised secret-shareholders according to a documented procedure.

8.1.1.1 CA Private Key Usage

The private key of the GCA-AA is used to sign issued certificates, the certification revocation lists and OCSP certificates. Other usages are restricted.

8.1.1.2 CA Private Key Type

For its primary key the GCA-AA makes use of the RSA SHA-1 algorithm with a key length of 2048 bits. The first GCA-AA private key is certified for validity from 27 January 2003 till 27 January 2009. New GCA-AA private keys will be certified for 6 years and 8 months. A new one will replace the active one before the validity period of the active one becomes less then 5 years.

8.1.2 CA Key Generation

The GCA-AA operator securely generates and protects the private key(s), using a trustworthy system, and takes necessary precautions to prevent the compromise or unauthorised usage of it. This process is witnessed by government representatives to ensure confidence of the government in the proper and secure execution of the GCA-AA Key Generation procedure. The GCA-AA implements and documents key generation procedures, in line with this CPS. The GCA-AA acknowledges public, international and European standards on trustworthy systems. At least three trusted operatives participate in the generation and installation of GCA-AA private key(s).


8.2 Key Pair re-generation and re-installation

When replacing secret key(s) by new ones, the GCA-AA must use exactly the same procedure as when initially generating key(s). Subsequently and without delay the GCA-AA must decommission and destroy (a) key(s) used in the past as well as the active tamper-resistant devices and all backup copies of its private key(s) as they become available.

8.2.1 CA Key Generation Devices

The generation of the private key of the GCA-AA occurs within a secure cryptographic device meeting appropriate requirements including FIPS 140-1 level 3.

8.2.1.1 CA Key Generation Controls

The generation of the private key of the GCA-AA requires the control of more than one appropriately authorised member of GCA-AA operator staff serving in trustworthy positions, and at least one representative of the government. More than one member of the GCA-AA operator management makes authorisation of key generation in writing.

8.2.2 CA Private Key Storage

The GCA-AA uses a secure cryptographic device to store its own private key meeting the appropriate FIPS 140-1level 3 requirements.

8.2.2.1 CA Key Storage Controls

The storage of the private key of the GCA-AA requires multiple controls by appropriately authorised members of GCA-AA operator staff serving in trustworthy positions. More than one member of the GCA-AA operator management makes authorisation of key storage and assigned personnel in writing.

8.2.2.2 CA Key Back Up

The GCA-AAs private key(s) is/are backed up, stored and recovered by multiple and appropriately authorised members of GCA-AA operator staff serving in trustworthy positions. More than one member of the GCA-AA operator management make authorisation of key back up and assigned personnel in writing.

8.2.2.3 Secret Sharing

The GCA-AA secret shares are held by multiple authorised holders, to safeguard and improve the trustworthiness of private key(s). The GCA-AA operator stores the private key(s) in several tamper-resistant devices. At least three members of the GCA-AA must act concurrently to activate the GCA-AA private key. Private keys of the GCA-AA may not be escrowed. The GCA-AA implements internal disaster recovery measures.

8.2.2.4 Acceptance of Secret Shares

Before secret shareholders accept a secret share they must personally have observed the creation, re-creation, and distribution of the share or its subsequent chain of custody.


A secret shareholder receives the secret share within a physical medium, such as a GCA-AA approved hardware cryptographic module. The GCA-AA keeps written records of secret share distribution.

8.2.3 CA Private Key Distribution

The GCA-AA documents its own private key distribution. In case token custodians need to be replaced in their role as token custodians, the GCA-AA will keep track of the renewed token distribution.

8.2.4 CA Private Key Destruction

At the end of their lifetime the GCA-AA private keys are destroyed by at least three trusted GCA-AA staff members at the presence of a representative of the Belgian State, in order to ensure that these private keys cannot ever be retrieved and used again. The GCA-AA keys are destroyed by shredding their primary and backup storage media, by deleting and shred their shares and by deleting, powering off and removing permanently any hardware modules the keys are stored on. Key destruction process is documented and any associated records are archived.

8.3 Private Key Protection and Cryptographic Module Engineering Controls

The GCA-AA uses appropriate cryptographic devices to perform GCA-AA key management tasks. These cryptographic devices are known as Hardware Security Modules (HSMs). These devices meet the requirements of FIPS 140-1 Level 3 or higher, which guarantees, amongst other things, that any device tampering is immediately detected and private keys cannot leave devices unencrypted Hardware and software mechanisms that protect GCA-AA private keys are documented. HSMs do not leave the secure environment of the GCA-AA premises. In case HSMs require maintenance or repair, which cannot be done within GCA-AA premises, they are securely shipped to their manufacturer. The GCA-AA private key(s) are not present on HSMs when those are shipped for maintenance outside the GCA-AA secure premises. Between usage-sessions HSMs are kept within the GCA-AA operator secure premises. The GCA-AA private key remains under n out of m multi-person control. The GCA-AA private key is not escrowed. At the end of a key generation ceremony, new GCA-AA keys are burnt encrypted on a (backup key storage) CD-ROM. The GCA-AA records each step of the key backup process using a specific form for logging information. The GCA-AA private key is locally archived within the GCA-AA operator premises. GCA-AA custodians are assigned with the task to activate and deactivate the private key. The key is then active for a defined time period. The GCA-AA private key can be destroyed at the end of its lifetime.


8.4 Other Aspects of Key Pair Management

The GCA-AA archives its own public key(s). The GCA-AA issues certificates with validity periods as indicated on such certificates.

8.4.1 Computing resources, software, and/or data corrupted

The GCA-AA establishes the necessary measures to ensure full and automatic recovery of the service in case of a disaster, corrupted servers, software or data. Any such measures are compliant with the ISO 1-7799 standard. The GCA-AA operator establishes disaster recovery resources sufficiently distant from the primary resources to avoid that a disaster would corrupt resources at both sites. The GCA-AA operator establishes sufficiently fast communications between the two sites to ensure data integrity. The GCA-AA operator establishes well-secured communications infrastructure from both sites to the RA, the Internet and networks of the Public Administration. The GCA-AA operator takes the necessary measures to test the disaster recovery infrastructure and procedures at least once a year without interruption or degradation of the service.

8.4.2 CA public key revocation

If a GCA-AA public key is revoked the GCA-AA will immediately:

Notify all GCA-AAs with whom it is cross-certified.

Notify the RA.

Notify the public at large through several channels that include:

A message on the GCA-AA website.

List the certificate of GCA-AA in CRLs and delta CRLs.

Update the certificate status in the Web interface service.

Revoke all certificates, signed with the revoked certificate. After assessing the reasons for revocation and taking measures to avoid the cause of revocation in the future, and after obtaining authorization from the RA, the GCA-AA may:

Generate a new key pair and associated certificate.

Re-issue all certificates that were revoked.

8.4.3 Compromise of the GCA-AA private key

If the private key of the GCA-AA is compromised, the corresponding certificate should immediately be revoked. The GCA-AA will additionally take all measures described under 6.4.2.

8.5 Activation Data

The GCA-AA securely stores and archives activation data associated with its own private key and operations.

8.6 Computer Security Controls

The GCA-AA implements certain computer security controls.


8.7 Life Cycle Security Controls

The GCA-AA performs periodic development controls and security management controls.

8.8 Network Security Controls

The GCA-AA operator maintains a high-level network of systems security including firewalls. Network intrusions are monitored and detected. In specific:

All communications between the GCA-AA operator and RA regarding any phase of the life cycle of Government certificates is secured with PKI based encryption and signing techniques, to ensure confidentiality and mutual authentication. This includes communications regarding certificate requests, issuance, suspension, unsuspension and revocation.

The GCA-AA website provides for encrypted connections through the Secure Socket Layer (SSL) protocol and anti-virus protection.

The GCA-AA operator network is protected by a managed firewall and intrusion detection system.

It is prohibited to access sensitive GCA-AA resources including GCA-AA databases from outside of the GCA-AA operators own network.

Internet sessions for request and delivery of information are encrypted.

8.9 Time-stamping



9. CERTIFICATE AND CRL PROFILES

This section specifies the certificate format, CRL and OCSP formats.

9.1 Certificate Profile

The GCA-AA publishes the certificate profiles it uses in its CPS. Certificates issued by the GCA-AA comply with IETF RFC 3280 and IETF RFC 3039.

9.1.1 Government CA Cerificate

Government CA-AA

Base Certificate OID Include Critical Value

Certificate

SignatureAlgorithm

Algorithm 1.2.840.113549.1.1.5 X SHA-1 with RSA Encryption Fixed

SignatureValue X Issuing CA Signature

TBSCertificate

Version X 2

SerialNumber X To be provided by FedICT 16 Bytes

Signature X Sha-1WithRSAEncryption

Validity

NotBefore X Key Genenration Process Date

NotAfter X Key Genenration Process Date + 6 years and 8

months

Fixed

SubjectPublicKeyInfo X RSA 2048

Issuer

CountryName { id-at-6 } X BE Fixed

CommonName { id-at-3 } X Under BRCA(1)

Belgium Root CA

Under BRCA2

Belgium Root CA2

Fixed

Subject


CommonName { id-at-3 } X Government CA Fixed

serialNumber X 9

Standard Extensions OID Include Critical Value

CertificatePolicies {id-ce 32} X FALSE

policyIdentifier X Under BRCA(1)

2.16.56.1.1.1.3

Under BRCA2

2.16.56.9.1.1.3

Fixed

policyQualifierrs N/a

policyQualifierId { id-qt-1 } X CPS Fixed

9 yyyy represents the year the GCA is issued.


Qualifier X http://repository.pki.belgium.be Fixed

KeyUsage {id-ce 15} X TRUE

CertificateSigning Set Fixed

crlSigning Set Fixed

authorityKeyIdentifier {id-ce 35} X FALSE

KeyIdentifier X SHA-1 Hash

subjectKeyIdentifier {id-ce 14} X FALSE

KeyIdentifier X SHA-1 Hash

cRLDistributionPoints {id-ce 31} X FALSE

distributionPoint

FullName X Under BRCA(1)

http://crl.pki.belgium.be/belgium.crl

Under BRCA2

Fixed

BasicConstraints {id-ce 19} X TRUE

CA X TRUE Fixed

pathLenConstraint X 0 (Zero) Fixed

NetscapeCertType X FALSE

2.16.840.1.113730.1.1 sslCA smimeCA ObjectSigning CA Fixed

9.1.1.1 Server Certificate

Server Certificate (issued automatically via RA interface + registration interface)


Certificate

SignatureAlgorithm

Algorithm X 1.2.840.113549.1.1.5 (SHA-1 with RSA Encryption) Fixed

SignatureValue X Issuing CA Signature Dynamic

TBSCertificate

Version X 2 Fixed

SerialNumber X Provided by the CA (11 bytes) Dynamic

Signature X Sha-1WithRSAEncryption Dynamic

Validity

notBefore X Key Genenration Process Date Dynamic

notAfter X Key Genenration Process Date + 1 years 3 month Dynamic

SubjectPublicKeyInfo X Provided by PKCS10 request Dynamic

Issuer



serialNumber X 10

Subject Required

CommonName { id-at-3 } YES Provided by PKCS10 request Dynamic

CountryName { id-at-6 } YES Provided by PKCS10 request Dynamic

eMail optional Provided by PKCS10 request Dynamic

Subject Serial Number optional Provided by PKCS10 request Dynamic

Locality optional Provided by PKCS10 request Dynamic

State or province optional Provided by PKCS10 request Dynamic

10

yyyy represents the year the GCA is issued.
http://crl.pki.belgium.be/belgium.crl


Organization Unit optional Provided by PKCS10 request Dynamic

Organization optional Provided by PKCS10 request Dynamic



PolicyIdentifier X 2.16.56.1.1.1.3.2 Fixed

PolicyQualifiers NA

PolicyQualifierId { id-qt-1 } X CPS Fixed

Qualifier X Http://repository.pki.belgium.be Fixed


NonRepudiation X Set Fixed

DigitalSignature X Set Fixed

KeyEncipherment X Set Fixed

DataEncipherment X Set Fixed

BasicConstraints {id-ce 19} X FALSE

CA X FALSE Fixed

PathLenConstraint X None Fixed

AuthorityKeyIdentifier {id-ce 35} X FALSE

SubjectkeyIdentifier X FALSE SHA-1 Hash Fixed

CRLDistributionPoints {id-ce 31} X FALSE

DistributionPoint X

FullName X http://crl.pki.belgium.be/government11

.crl Fixed

NetscapeCertType 2.16.840.1.113730.1.1 X FALSE

SSL Server X Set Fixed

S/MIME X Set Fixed

AuthorityInfoAccess {id-pe 1} X FALSE

AccessMethod { id-ad-2 } X

AccessLocation X http://certs.pki.belgium.be/belgiumrs.crt

Points to GlobalSign Signed Government top root CA.

Fixed


AccessLocation X http://ocsp.pki.belgium.be Fixed

9.1.1.2 Applications Certificate

Applications Certificate (issued automatically via RA interface + registration interface)


Certificate

SignatureAlgorithm



TBSCertificate

Version X 2 Fixed



Validity

notBefore X Key Genenration Process Date Dynamic

notAfter X Key Genenration Process Date + 1 years 3 month Dynamic

11



SubjectPublicKeyInfo X Provided by PKCS10 request Dynamic

Issuer



serialNumber X 12

Subject Require

d

CommonName { id-at-3 } YES Provided by PKCS10 request Dynamic

CountryName { id-at-6 } YES Provided by PKCS10 request Dynamic

eMail optional Provided by PKCS10 request Dynamic

Subject Serial Number optional Provided by PKCS10 request Dynamic

Locality optional Provided by PKCS10 request Dynamic

State or province optional Provided by PKCS10 request Dynamic

Organization Unit optional Provided by PKCS10 request Dynamic

Organization optional Provided by PKCS10 request Dynamic



PolicyIdentifier X 2.16.56.1.1.1.3.3 Fixed

PolicyQualifiers NA

PolicyQualifierId { id-qt-1 } X CPS Fixed

Qualifier X Http ://repository.pki.belgium.be Fixed


NonRepudiation X Set Fixed

DigitalSignature X Set Fixed

KeyEncipherment X Set Fixed

DataEncipherment X Set Fixed

BasicConstraints {id-ce 19} X FALSE

CA X FALSE Fixed

PathLenConstraint X None Fixed

AuthorityKeyIdentifier {id-ce 35} X FALSE

SubjectkeyIdentifier X FALSE SHA-1 Hash Fixed

CRLDistributionPoints {id-ce 31} X FALSE

DistributionPoint X

FullName X http://crl.pki.belgium.be/government13

.crl Fixed

NetscapeCertType 2.16.840.1.113730.1.1 X FALSE

SSL Client X Set Fixed

S/MIME X Set Fixed

Object Signing X Set Fixed

AuthorityInfoAccess {id-pe 1} X FALSE


AccessLocation X http://certs.pki.belgium.be/belgiumrs.crt

Points to GlobalSign Signed Government top root CA.

Fixed


AccessLocation X http://ocsp.pki.belgium.be Fixed

12

yyyy represents the year the GCA is issued. 13



9.1.1.3 Persons Certificate

Persons Certificate (issued automatically via RA interface + registration interface)


Certificate

SignatureAlgorithm



TBSCertificate

Version X 2 Fixed



Validity

notBefore X Key Genenration Process Date

Documents

Government CA Certification Practice Statement v1.0