Content

Publisher's imprint

Content

1 Introduction

1.1 Overview

1.1.1 Policy Authority for the PKI for the government

1.1.2 CA model PKIoverheid (non RFC3647)

1.2 Document name and identification

1.2.1 Objective of CPS (non RFC3647)

1.2.2 Relationship between CPS and CP (non RFC3647)

1.2.3 CA/Browser Forum Baseline Requirements (non RFC3647)

1.2.4 Certificate Policies (CPs) (non RFC3647)

1.3 Involved parties

1.4 Certificate usage

1.5 Policy management

1.5.1 Organization responsible for managing the CPS

1.5.2 Contact information

1.5.3 The person who verifies the eligibility of CPS for the CP

1.5.4 Change procedure CPS

1.6 Definitions and abbreviations

1.7 Guarantees (non RFC3647)

1.8 Verification of trustworthiness (non RFC3647)

1.8.1 Trustworthiness of the issuing government body (non RFC3647)

1.9 Programme of Requirements and framework consultation PKIoverheid (non RFC3647)

2 Publication and electronic repository responsibilities

2.1 Electronic repository

2.2 Publication certificate information

2.2.1 Official electronic notification (non RFC3647)

2.2.2 Distribution Public Key (non RFC3647)

2.3 Frequency of Publication

2.4 Access to publication

3 Identification and Authentication

3.1 Naming

3.1.1 Types of names

3.1.2 Requirement for the use of meaningful names

3.1.3 Pseudonyms

3.1.4 Rules for interpreting various name forms

3.1.5 Uniqueness of names

3.1.6 Recognition, authentication an d role of trademarks

3.2 Initial identity validation

3.2.1 Initial Registration Process

3.2.2 Authentication of organizational identity

3.2.3 Authentication of individual identity

3.3 Identification and authentication when renewing a certificate

3.4 Identification and authentication when a certificate is revoked

4 Operational requirements of the certificate lifecycle

4.1 Scope

4.2 Certificate Application

4.2.1 Methodology with regard to creating certificates

4.3 Certificate Issuance

4.4 Certificate Adoption

4.5 Key Pair and Certificate Usage

4.6 Certificate Renewal

4.7 Certificate Rekey

4.8 Certificate Modification

4.9 Certificate Revocation and Suspension

4.10 Certificate Status Services

4.10.1 Operational characteristics of the Certificate Status Service

4.10.2 Certificate Status Service availability

4.10.3 Optional attributes of the certificate status service

4.11 Termination

4.11.1 Transfer of PKIoverheid

4.12 Key escrow and key recovery

4.13 Registration of certificate holders (non RFC3647)

5 Physical, procedural and personnel security

5.1 Physical Security

5.2 Procedural Security

5.3 Personnel security

5.4 Audit logging procedures for security audits

5.5 Documents Archival

5.6 Key Renewal

5.7 Compromise and continuity

6 Technical Security

6.1 Key Pair Generation and Installation

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.3 Other aspects of key pair management

6.4 Activation data

6.5 Control measures for computer systems

6.6 Life Cycle Technical Control Measures

6.7 Network Security

6.8 Registrations

6.9 Cryptographic algorithms (non RFC3647)

7 Certificate and CRL profiles

7.1 Certificate Profiles

7.2 CRL profiles

7.3 OCSP profiles

8 Conformity assessment

8.1 Frequency and circumstances of the conformity assessment

8.2 Identity, qualifications of the auditor

8.3 Topics covered by the conformity assessment

8.4 Actions based on deviations

8.5 Communicating the results

8.6 Admittance of TSPs to the PKI for the government

9 Other Business and Legal Matters

9.1 Fees

9.2 Financial Responsibility and Liability

9.3 Confidentiality of company data

9.4 Confidentiality of personal data

9.5 Intellectual Property Rights

9.6 Liability and obligations

9.7 Disclaimers of liability

9.8 Limitations of Liability

9.9 Indemnities

9.10 Term of validity and dissolution CPS

9.11 Agreements and communication between entities from the PKIoverheid hierarchy

9.12 Changes

9.13 Dispute Resolution Provisions

9.14 Governing Law

9.15 Compliance with the relevant legislation

Appendix A. Wording of Root Certificate announcement

Appendix B. Procedures for the change control of the PoR PKIoverheid

Appendix C. Certificate profile TSP CA G3

Appendix D. Content fields G2 root certificates and domain certificates

Appendix F. Content fields G3 root certificates and domain certificates

Revision history

1 Introduction

1.1 Overview

1.1.1 Policy Authority for the PKI for the government

The Policy Authority of the PKI for the government (PA PKIoverheid) supports the Minister of the Interior and Kingdom Relations (MinBZK) in managing the PKI for the government.

The PKI for the government is a framework which enables generic and large-scale use of the electronic signature, and it also facilitates remote identification and confidential communication.

The tasks of the PA of PKIoverheid are:

1. contributing towards the development and the maintenance of the framework of standards that underlies the PKI for the government, the Programme of Requirements (PoR);

2. assisting in the process of admittance by Trust Service Providers (TSPs) to the PKI for the government and preparing the administration;

3. regulating and monitoring the activities of TSPs that issue certificates under the root of the PKI for the government.

The Policy Authority (PA) is responsible for managing the entire infrastructure. The PKI for the government is structured in such a way that external organizations, the Trust Service Providers (TSPs), can be admitted to the PKI for the government under certain conditions. Participating TSPs are responsible for the services within the PKI for the government. The PA oversees the trustworthiness of the entire PKI for the government[1].

Within the scope of PKIoverheid, the PA is generally responsible for:

1. management of the standards system of the PKI for the government, the Programme of Requirements parts 3a through e;

2. management of Object Identifiers, the unique numbers for TSPs and their CPSs;

3. creation and management of key pair and the corresponding root certificate;

4. revoking the root certificate and ad-hoc publication of the CRL;

5. periodic publication of the CRL;

6. creation and management of key pairs and the corresponding domain certificates;

7. revocation of domain certificates and ad-hoc publication of the corresponding CRL;

8. preparation concerning the admission of TSPs to the PKIoverheid;

9. implementation of the admission of TSPs, including creation, issuance and management of TSP CA certificates;

10. preparation concerning the revocation of TSP CA certificates;

11. implementation of the revocation of TSP CA certificates;

12. supervision of permitted TSPs;

13. preparation concerning the renewal of TSP CA certificates;

14. implementation of the renewal of TSP CA certificates, including creation, issuance and management of new TSP CA certificates;

15. registration and assessment of reports regarding infringement of the PKIoverheid.

KPN BV is responsible for the technical management of Staat der Nederlanden Root CA and Staat der Nederlanden <Domain> CA, the corresponding Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCPS) responders.

The management of root certificates and domain certificates is entrusted to the Policy Authority of the PKI for the government. This organization is part of Logius (http://www.logius.nl), digital government service of the Ministry of the Interior and Kingdom Relations.

The purpose of the Policy Authority is:

Maintaining a practicable and trustworthy framework of standards for PKI services that provides an established level of security for the government's communication needs and which is transparent for the users.

1.1.2 CA model PKIoverheid (non RFC3647)

The government's Public Key Infrastructure (PKI) has a structure consisting of a central and an operational or local level; there is a structure or root based on the SHA-256 algorithm. Furthermore a division is made into different domains. Under the G2 (SHA-256) root there are domains for Organization, Citizen and Autonomous Devices. Under the G3 (SHA-256) root there are domains for Organization Person, Organization Services, Citizen and Autonomous Devices

In the past, there was also a first generation PKIoverheid root (G1); however this expired in December 2015 and will not be covered in this CPS.

The root and the domains based on the SHA-256 algorithm are denoted as G2 and G3, where the 'G' stands for generation.

Within the central part of the PKI for the government, a number of actors are identified. These actors are (see Figure 1):

1. the Government PA, responsible at the highest level for laying down the policy and general standards that apply within the PKI for the government and the issue of certificates;

2. the Government CA, relates to a technical component that produces the highest (or root) certificate within the PKI for the government and produces certificates for the underlying domain CAs;

3. the Domain PA, responsible for the domain-specific content of the Government PA standards, and determines the conditions of the issue of certificates within a domain;

4. the Domain CA relates to a technical component that actually produces certificates for the TSPs.

The coordinating government level and the domain level form the PKI's policy structure. Within these levels, policy and standards are laid down and the supervision is organized.

The TSP level is the operational or local part of the Public Key Infrastructure (PKI) for the government, where the direct interaction with the users takes place. At TSP level, the TSP organization is ultimately responsible for issuing certificates.

1.2 Document Name and Identification

The Certification Practice Statement within the PKI for the government (hereinafter referred to as CPS) provides TSPs, subscribers, relying parties and certificate holders with information regarding the procedures and measures taken in respect of the PA's services with regard to certificates. The CPS describes the processes, procedures and control measures for applying for, producing, issuing, managing and revoking certificates, insofar as the PA is directly responsible for this. This means that this CPS only relates to PKIoverheid Level 1 (Staat der Nederlanden Root CA) and Level 2 (Staat der Nederlanden <Domain> CA).

This CPS also describes the processes and procedures for applying for, producing, issuing and revoking Level 3 <TSP name> CA certificates.

For a description of the processes, procedures and control measures for applying for, producing, issuing, managing and revoking Level 4 (end user) certificates, please refer to the relevant Certification Practice Statements of the PKIoverheid Trust Service Providers

The format of this CPS is, as far as possible, in accordance with the RFC3647^[2] standard (in full: “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework”) of the Internet Engineering Task Force. When this CPS deviates from the RFC3647 standard this is indicated by adding ‘non RFC3647’ to the title of the segment in question.

Formally, this document is referred to as the 'Certification Practice Statement certificates within the PKI for the government'.

The PA publishes two language versions of this CPS; English and Dutch. Great care is taken in ensuring parity in both language versions. In case of discrepancies between the English version and the Dutch version of this document, the English version shall prevail.

Public information about the PA or the PKI for the government is available at http://www.logius.nl/pkioverheid.

1.2.1 Objective of CPS (non RFC3647)

This CPS provides information to TSPs, subscribers, relying parties and certificate holders regarding the procedures and measures taken with regard to the PA's services. The quality of the services underpins the trust that can be placed in the PKI for the government. In this respect, the relationship between the PA and Trust Service Providers (TSPs) is also of importance. This relationship and the conditions under which TSPs can participate in the PKI for the government are broadly described. TSPs interested in participating in the PKI for the government can obtain more detailed information about this subject from the PKIoverheid Programme of Requirements part 2.

1.2.2 Relationship between CPS and CP (non RFC3647)

The CP PoR parts 3a through e describe the minimum requirements stipulated in relation to the services of a TSP within PKIoverheid. This CPS states how the PKIoverheid services will be put into practice, insofar as this is under the direct responsibility of the PA.

1.2.3 CA/Browser Forum Baseline Requirements (non RFC3647)

The PA of PKIoverheid conforms to the current version of the Baseline Requirements for Issuance and Management of Publicly-Trusted Certificates as published at http://www.cabforum.org. In the event of any inconsistencies between the PKIoverheid Programme of Requirements parts 3b and 3e [2.16.528.1.1003.1.2.2.6 and 2.16.528.1.1003.1.2.5.6] and the relevant Requirements, causing the inability to fulfill the minimum requirements put forth herein, the provisions in the Baseline Requirements shall prevail.”

1.2.4 Certificate Policies (CPs) (non RFC3647)

This part relates to the requirements laid down for the services of a Trust Service Provider (TSP). Nine areas are identified, each of which are covered in a separate part, which are:

Part 3a – Certificate Policy for Organization and Organization Person Domain;

Part 3b – Certificate Policy for Organization and Organization Services Domain;

Part 3c – Certificate Policy for Citizen Domain;

Part 3d – Certificate Policy for Autonomous Devices Domain;

Part 3e – Certificate Policy for Server Certificates.

Part 3f – Certificate Policy for Extended Validation

Part 3g – Certificate Policy for Private Services

Part 3h – Certificate Policy for Private server certificates

Part 3i – Certificate Policy for Private Persons

This CPS only relates to CP parts 3a through 3e. The “CPS Policy Authority PKIoverheid for Extended Validation certificates to be issued by the Policy Authority of the PKI for the government" relates to CP part 3f.The “CPS Policy Authority PKIoverheid for Private Root certificates to be issued by the Policy Authority of the PKI for the government” relates to CP parts 3g through 3i.

1.2.4.1 Positioning Programme of Requirements (non RFC3647)

The Programme of Requirements forms the basis of the PA's services. Laid down in the Programme of Requirements are the requirements for the PKI for the government; these requirements are derived from international standards and the applicable legislation. The Programme of Requirements is made up of four parts and in each part, a specific aspect of the PKI for the government is elaborated on in further detail.

1.2.4.2 Introduction Programme of Requirements (non RFC3647)

This part includes an introduction to the Programme of Requirements and the PKI for the government.

1.2.4.3 Admittance and supervision (non RFC3647)

Part 2 describes how a TSP can be admitted to the PKI for the government, can demonstrate compliance with the requirements and which formalities have to be met. It also describes how the PA regulates the TSPs that have been admitted.

1.3 PKI Participants

In this CPS, six parties are identified, each with their own responsibility within the PKI for the government. Consecutively, these parties are:

1. the Ministry of the Interior and Kingdom Relations;

2. the Policy Authority (PA);

3. the Trust Service Provider (TSP);

4. Subscriber;

5. Certificate holder;

6. the relying party.

The responsibilities and the corresponding activities for each of these parties are briefly described below.

The Ministry of the Interior and Kingdom Relations is responsible for the PKI for the government. The Ministry of the Interior and Kingdom Relations makes decisions regarding the layout of the infrastructure and the participation of TSPs in the PKI for the government. The director of Logius represents the Ministry of the Interior and Kingdom Relations in this matter.

The PA advises the director of Logius and is responsible for managing the central part^[3] of the PKI for the government and supervising and monitoring the work of TSPs that issue certificates under the Staat der Nederlanden Root CA of the PKI for the government.

One or more TSPs operate in each domain of the PKI for the government. Within a domain of the PKI for the government, a TSP will issue certificates to the certificate holders. The obligations of the TSPs that form part of the PKI for the government are defined in the Programme of Requirements, parts 3a through 3e: Certificate Policies.

A subscriber enters into an agreement with a TSP on behalf of one or more certificate holders. How the delivery of certificates takes place is organized between the subscriber and the TSP.

The certificate holder is the holder of the private key belonging to the public key contained in the certificate. Certificate holders can be found at all levels in the hierarchy of the PKI for the government. End users receive the certificates from the TSPs. The PA issues certificates to itself (Staat der Nederlanden Root CA and Staat der Nederlanden <Domain> CAs) and to TSPs (TSP CA).

The relying party is the recipient of a certificate issued within the PKI for the government and acts on the basis of trust in the certificate. The relying party is obliged to check the validity of the full chain of certificates through to the source (root certificate) on which trust is placed. This obligation is included in the Programme of Requirements, part 3: Certificate Policies.

1.4 Certificate Usage

Within the PKI for the government, different types of certificates are defined at four levels, which are:

· Root certificate;

· Domain certificate;

· TSP certificate;

· End user certificate.

The root certificate, the domain certificates and the TSP certificates can only be used to verify the issuer's signature and are issued by the Policy Authority. These certificates may not be used for other purposes. The end user certificate is issued by the TSPs. End user certificates can be used for authenticity, non-repudiation, confidentiality and a combination of authenticity and confidentiality.

This CPS relates to the trustworthiness of the Policy Authority's services, therefore this paragraph only covers the procedures relating to root, domain and TSP certificates.

1.5 Policy Administration

1.5.1 Organization responsible for managing the CPS

The Ministry of the Interior and Kingdom Relations is responsible for this CPS. The Ministry has delegated this task to Logius. This also includes the approval of changes to this CPS.

1.5.2 Contact information

Should there be any complaints, questions or alerts, TSPs within the PKIoverheid framework can contact staff of the PA PKIoverheid through the usual channels. The PA PKIoverheid is available during office hours and will respond as quickly as possible. In the event of reports of incidents or emergencies outside of office hours, the Logius Service Centre should be contacted, which is available 24 hours a day.

Subscribers who have questions concerning the issuance of certificates are asked to initially contact their (potential) TSP.

Other involved parties can contact the Logius Service Centre. The service centre registers the question and will answer this within the stipulated period of time. If necessary, questions asked through the service centre are forwarded to the PA PKIoverheid, or in the event of an incident, to the on-duty incident manager.

Contact information

Policy Authority PKIoverheid

Wilhelmina van Pruisenweg 52

P.O. Box 96810

2509 JE THE HAGUE

http://www.logius.nl/pkioverheid

General telephone number: +31(0)708896360

Email: servicecentrum@logius.nl

1.5.3 The person who verifies the eligibility of CPS for the CP

The PA PKIoverheid does not have its own Certificate Policy. Approval of the CPS is discussed in 1.5.4.

1.5.4 Change procedure CPS

The PA of PKIoverheid is entitled to change or to add to this CPS. Changes apply as from the time that the new CPS is published, in accordance with the provisions in paragraph 9.10. The management of Logius is responsible for observing the procedure described in paragraph 9.12 accurately and for the ultimate approval of this CPS in accordance with this procedure.

1.6 Definitions and Acronyms

In part 4 of the PoR, an explanation is given regarding the definitions and acronyms used in the Programme of Requirements.

For a list of the used definitions and acronyms, please refer to http://www.logius.nl/begrippenlijst (in Dutch).

1.7 Guarantees (non RFC3647)

When issuing PKIoverheid certificates, the following parties are recognized:

A. Subscriber;

B. End user;

C. Organizations that develop internet browser software;

D. Relying parties.

These parties are informed that:

The PA of PKIoverheid guarantees that sub-CAs within the PKIoverheid framework are known to the PA and remain under the control of the TSP that has created a sub-CA. In addition these sub-CAs shall not be used for man-in-the middle (MITM) purposes.

All sub-CA certificates issued within the PKI for the government are listed on this website:

https://cert.pkioverheid.nl

PKIoverheid and its Trust Service Providers guarantee that, during the time that a PKIoverheid services - server certificate is valid, when a PKIoverheid services - server certificate is issued, they have adhered to the requirements from the CA/Browser Forum Baseline Requirements and the PoR parts 3b and 3e [2.16.528.1.1003.1.2.2.6 and 2.16.528.1.1003.1.2.5.6] and that they checked the information included in the services - server certificate for accuracy and completeness.

For a description of the safeguards, please refer to the relevant Certification Practice Statements of the PKIoverheid Trust Service Providers.

1.8 Verification of trustworthiness (non RFC3647)

In figure 2, the structure is presented from the point of view of the relying parties. A relying party has a certificate (4) of another party (the certificate holder) and requires certainty regarding the trustworthiness of this certificate. A certificate is verified by performing the following checks [4]:

· Has the message been changed whilst being sent, (e.g. is the integrity safeguarded?)

· Has the certificate that has been used been revoked and included on a so-called "black list"?

· Is the certificate still valid?

·

The software then establishes whether the certificate has been issued by a trusted party. To be able to perform this final verification, the software has to have the root certificate of the PKI for the government. If the root certificate is not available, the user receives an error message. That is why the PA has decided to include the root certificate in frequently used operating systems and (Open Source) browsers.

When software is used in which the root certificate is not included, the relying party can securely download the root certificate at https://cert.pkioverheid.nl

The TSP certificate (3) is issued by the PA and can be verified using the domain certificate (2). This latter certificate is also issued by the PA and can be verified using the root certificate (1). At each level of the PKI for the government, the trust in a certificate therefore depends on the trust placed in the party that has issued the certificate. From a relying party's point of view, this is the TSP for the first verification step, the PA for the second step at domain level and finally the PA at the highest level of the hierarchy. The root certificate is therefore the pivotal point of trust in the hierarchy of the PKI for the government and determines the trust placed in all other certificates issued within the PKI for the government. By expressing the trust in the root certificate, all underlying domain, TSP and end user certificates are trusted. The users only have to trust one certificate. An important aspect is determining the trustworthiness of the government body that issues the certificate.

1.8.1 Trustworthiness of the issuing government body (non RFC3647)

To be able to trust a certificate, the relying party has to determine whether it wishes to place trust in the issuing government body (the TSP). The relying party can do this by assessing the Certification Practice Statement (CPS) of the TSP. The certificate contains a reference to the CPS. To avoid a relying party having to assess every CPS of the TSPs within the PKI for the government in detail, the hierarchy of the PKI for the government was created. The conditions for issuance, management and also the use of end user certificates are described by the PA in the so-called CP. The CP is therefore key to the CPS of the various TSPs active within the PKI for the government.

For there to be a trustworthy hierarchy, it is therefore very important that the PA operates in a trustworthy manner. The PA safeguards the trustworthiness of the root certificate and the domain certificates by applying effective security measures. These security measures, as well as the way in which the PA regulates the TSPs, are described in this CPS of the PA. By assessing the CPS of the PA, the relying party can determine whether they trust a certificate that is issued within the hierarchy of the PKI for the government. In addition, the trustworthy operation of the PA is ratified periodically by an audit being performed by external auditors.

1.9 Programme of Requirements and PKIoverheid Framework Council (non RFC3647)

The Programme of Requirements is the formal framework of standards in respect of the trustworthiness and quality of services within the PKI for the government. While the PA maintains these standards, it is important that the practical experiences and ideas of users are also taken into account. To be able to generate this support for the use of the Programme of Requirements, a PKIoverheid Framework Council has been set up that is consulted regarding decision-making about change proposals in respect of the Programme of Requirements. The Council also discusses subjects that are generally relevant to the PKI developments.

The full set of procedures for the change control of the Programme of Requirements of PKIoverheid is attached as Annex B.

2 Publication and Repository Responsibilities

2.1 Electronic repository

The PA publishes the root certificate, the domain certificates and the TSP certificates on its website. Also available on the website is information regarding the use of the root certificate, the domain certificates and the TSP certificates.

An admitted TSP publishes the TSP certificates issued by the PA on its own website. A reference is also included to the root certificate and the domain certificates on the PA's website.

The CRLs relating to the end user certificates can be found on the websites of the various TSPs.

2.2 Publication certificate information

The following certificates are published:

• Staat der Nederlanden Root CA – G2;

• Staat der Nederlanden Burger CA – G2;

• Staat der Nederlanden Organisatie CA – G2;

• Staat der Nederlanden Autonome Apparaten CA - G2;

• Staat der Nederlanden Root CA – G3;

• Staat der Nederlanden Burger CA – G3;

• Staat der Nederlanden Organisatie Services CA – G3;

• Staat der Nederlanden Organisatie Persoon CA – G3;

• Staat der Nederlanden Autonome Apparaten CA – G3;

• <Name TSP> CA – G2;

• <Name TSP> CA – G3.

This CPS can be found at the following URL:

https://cps.pkioverheid.nl

The following CRLs are published. These can also be found on the website https://crl.pkioverheid.nl. Below are the direct links to the CRLs:

• For revoked State of the Netherlands CA domain certificates: http://crl.pkioverheid.nl/RootLatestCRL-G2.crl http://crl.pkioverheid.nl/RootLatestCRL-G3.crl

• For revoked TSP CA certificates:

http://crl.pkioverheid.nl/DomOrganisatieLatestCRL-G2.crl http://crl.pkioverheid.nl/DomBurgerLatestCRL-G2.crl http://crl.pkioverheid.nl/DomAutonomeApparatenLatestCRL-G2.crl

http://crl.pkioverheid.nl/DomOrganisatieServicesLatestCRL-G3.crl

http://crl.pkioverheid.nl/DomOrganisatiePersoonLatestCRL-G3.crl

http://crl.pkioverheid.nl/DomBurgerLatestCRL-G3.crl

http://crl.pkioverheid.nl/DomAutonomeApparatenLatestCRL-G3.crl

2.2.1 Official electronic notification (non RFC3647)

The attributes of the root certificates are published in the Official Gazette (Staatscourant) and attached as Appendix A

1. G2: published in the Official Gazette (Staatscourant) dated 15 December 2008 (no. 243, page 1);

2. G3: published in the Official Gazette (Staatscourant) dated 10 April 2014 (no. 10020, page 1).

2.2.2 Distribution Public Key (non RFC3647)

The public key of the root certificate is distributed through the trusted root certificate programmes of various software suppliers. An up-to-date list of the software products containing the PKIoverheid root certificate can be found at https://www.logius.nl/ondersteuning/pkioverheid/browserondersteuning-pkioverheid/.

The root certificate is also provided in a trustworthy manner at https://cert.pkioverheid.nl.

2.3 Frequency of Publication

The information in the electronic repository will be published or updated as quickly as possible. When a new version of the CPS is published, the TSPs participating in the PKIoverheid framework will be informed by email.

The PA publishes the lists of revoked certificates, the Certificate Revocation Lists (CRLs). There is a CRL with revoked domain certificates. This CRL is republished annually. This CRL is published ad-hoc after revocation of a domain certificate. For each domain, there is a CRL with revoked TSP certificates within that domain. A domain CRL is republished every six months. A domain CRL is published ad-hoc after revocation of a TSP certificate.

Each CRL contains the time of the next planned CRL release. These CRLs can be found at: https://crl.pkioverheid.nl.

As well as the publication of the CRL, the PA also offers status information for the Organization Services domain through the Online Certificate Status Protocol (OCSP). To this end, the following two OCSP have been set up.

1. http://RootOCSP-G3.OCSP.pkioverheid.nl provides status information about the Organization Services domain certificate;

2. http://DomOrganisatieServicesOCSP-G3.OCSP.pkioverheid.nl provides status information about the TSP certificates in the Organization Services domain.

The OCSP responders conform to RFC2560[5].

2.4 Access to publication

Published information is public in nature and freely accessible. The Electronic Repository can be accessed twenty-four hours a day, seven days a week. The Electronic Repository is protected against unauthorized changes being made.

In the event of system failure or other factors that have a negative impact on the availability of the Electronic Repository, an appropriate set of continuity measures have been prepared to ensure that the CRL will be available again within 4 hours and the other parts of the Electronic Repository within 24 hours. An example of such a measure is having created a fall-back facility and scenario. In addition, every year the repository will undergo a penetration test. This is carried out by an external IT security company.

3 Identification and Authentication

3.1 Naming

3.1.1 Types of names

All certificates issued by the PA of PKIoverheid contain a 'subject' field (DistinguishedName) which lists the name of the holder. The names used in the certificates fulfill the X.501 name standard. The names consist of the following components:

Figure 3 - Staat der Nederlanden G2

Figure 4 - Staat der Nederlanden G3

For other provisions regarding the way in which identification and authentication take place within PKIoverheid, please refer to the relevant Certification Practice Statements of the PKIoverheid Trust Service Providers.

3.1.2 Requirement for the use of meaningful names

There are no other provisions in this respect for the certificate services by the PA.

3.1.3 Pseudonyms

The use of pseudonyms or anonymous certificates is not permitted.

3.1.4 Rules for interpreting various name forms

The name of the TSP CA is copied from the extract in the Dutch Trade Register.

3.1.5 Uniqueness of names

All certificates issued under this CPS, contain a unique subject field (DistinguishedName).

3.1.6 Recognition, authentication and role of trademarks

The PA assumes the correctness of the name of organizations as listed in the Dutch Trade Register of the Chamber of Commerce.

3.2 Initial Identity Validation

3.2.1 Initial Registration Process

For the requirements laid down in relation to the initial registration process, see the PKIoverheid Programme of Requirements, part 2.

3.2.2 Authentication of organizational identity

Based on the application form and the evidence that is supplied, the PA verifies,

· that the TSP is an existing organization listed in the National Trade Register (NHR) or an organizational entity that forms part of an existing organization listed in the NHR. If a government organization is not listed in the NHR, the State Almanac is consulted;

· that the name of the organization and country name registered by the TSP to be incorporated in the certificate are correct and complete and that the applicant is authorized to represent the organization;

· the presence of the relevant registration information of the prospective TSP, with the corresponding evidence (excerpt from the Chamber of Commerce, etc.). The excerpt must be original and must not be older than 13 months.

Note: If the participating party has existed for less than three years and does not appear in the latest version of the quoted registration sources, the identity and validity of the prospective TSP can be, if required, established using a parent company or parent ministry that are registered in the NHR or the State Almanac.

3.2.3 Authentication of individual identity

Upon initial admittance to the PKIoverheid framework, the PA verifies the listed personal data of the authorized representative of the TSP using an identity document issued under art. 1 of the Compulsory Identification Act:

· a valid travel document referred to in the Passport Act (Paspoortwet);

· a valid driving license issued on the basis of the Road Traffic Act (Wegenverkeerswet), under article 107 of the Road Traffic Act (Wegenverkeerswet) 1994.

3.3 Identification and Authentication for Re-key Requests

Often, a TSP has already been admitted to PKIoverheid when a new TSP CA has to be created under a new generation of the regular root. It is also possible that a TSP that has already been admitted wishes to issue certificates under a new domain or a different root. In that case, an abbreviated procedure can be applied for the identification validation, because the TSP CA is already known to the PA and has been admitted to PKIoverheid.

It is then sufficient for the PA to verify whether the organization name and name of the country provided in the Naming document/CSR is still correct. This can be verified as follows:

1. By online consultation of the NHR to verify whether the TSP CA is an existing organization;

2. By online consultation of a database such as Dunn & Bradstreet, which is kept up-to-date and which is considered to be a trustworthy source.

In addition, the PA must verify that the application came from the actual TSP CA. An application can be submitted in two ways:

1. The authorized representative can send an application form by email and sign this using a PKIoverheid certificate;

2. The authorized representative can sign an application form and send this by post.

In the second case, the registered authorized representative of the TSP CA should also be contacted by the PA to verify the application. For purposes of verification, identifying details of the contact person or organization can be requested.

This identification verification by the PA is recorded and archived in the TSP CA file.

3.4 Identification and Authentication for Revocation Requests

A request for revocation of a certificate can be submitted by the TSP CA. When a request for revocation is made, the reasons for this must always be given. In consultation with the parties involved, it will be examined to what extent the request can be complied with, as revocation of a TSP CA means that the underlying certificates will no longer be valid.

Identification and authentication of the party submitting the request to revoke the TSP CA can take place as follows:

· A request by email to the PA, where the request is signed digitally with a qualified electronic signature;

· A request by signed letter;

In both cases, the PA will contact the authorized representative of the TSP CA by telephone to establish whether the request for revocation is genuine. For purposes of verification, identifying details of the contact person or organization can be requested.

4 Certificate Life-Cycle Operational Requirements

4.1 Scope

Within the PKI for the government, different types of certificates are defined at four levels, which are:

· Root certificate;

· Domain certificate;

· TSP certificate;

· End user certificate.

The root certificate, the domain certificates and the TSP certificates can only be used to verify the issuer's signature and are issued by the Policy Authority. These certificates may not be used for other purposes. The end user certificate is issued by the TSPs.

This CPS relates to the trustworthiness of the Policy Authority's services, therefore this paragraph only covers the procedures relating to root, domain and TSP certificates.

4.2 Certificate Application

The root certificate, the domain certificates and TSP certificates are created by the Policy Authority, at the instruction of the Ministry of the Interior and Kingdom Relations.

The instruction to create TSP CA certificates is by means of a request to this end by a TSP. For more information, see PKIoverheid PoR part 2.

When TSP CAs are signed, the PA PKIoverheid does not verify CAA records.

4.2.1 Methodology with regard to creating certificates

The root certificate, the domain certificates and TSP certificates are created during special creation ceremonies. A certified external IT auditor acts as witness during the creation ceremonies of the Staat der Nederlanden Root CA and Staat der Nederlanden <Domain> CA. A certified external IT auditor is also present as witness during the creation of the TSP CAs. For every creation ceremony, a detailed script is produced which lists all tasks to be carried out. This main purpose of this script is to prevent any input errors during the ceremony. A creation ceremony takes place in accordance with the script in the presence of independent witnesses. The identity of the persons present is verified using the valid documents referred to under article 1 of the Compulsory Identification Act (“Wet op de identificatieplicht”).

The creation ceremonies take place in a similar manner for all of the listed types of certificates, where the certificate holder is either the PA or the TSP. During the ceremony, the following steps take place:

1. building the computer system;

2. installing and configuring the PKI software;

3. activating the Hardware Security Module (HSM), where several key holders each introduce part of the activation data;

4. generating the key pairs;

5. generating certificates for each key pair;

6. dismantling the computer system and

7. securing the computer system and the critical components.

4.3 Certificate Issuance

The requirements which a TSP must fulfill when issuing the certificates are formulated in part 3 (Certificate Policies) of the Programme of Requirements. The way in which a TSP implements these requirements must be defined by the TSP itself in a Certification Practice Statement (CPS). The description of the services by TSPs therefore falls outside the scope of the specification of this CPS.

There is no separate CP for the issuance of certificates by the PA, as the PA does not issue end user certificates. The measures that the PA has taken to guarantee the trustworthiness of the certificates to be issued by the PA are described in this CPS.

4.4 Certificate Acceptance

The script associated with the creation ceremonies also contains the procedure for ascertaining the accuracy and accepting the certificates that are created. Also listed in the script are the names of the people involved. The PA establishes the accuracy of the certificates. The TSP then accepts the TSP certificates.

4.5 Key Pair and Certificate Usage

The Staat der Nederlanden Root CA, Staat der Nederlanden <Domain> CAs and the TSP CAs certificates are primarily used to verify the issuer's signature and are issued by the PA. These certificates are also used for CRL signing. These certificates may not be used for other purposes. The end user certificate is issued by the TSPs.

4.6 Certificate Renewal

Certificates have to be renewed when (part of) the information that forms the basis of the certificate changes or is out of date. For example, if the name of a TSP as included in the certificate changes or if the strength of a cryptographic algorithm is deemed insufficient and a stronger cryptographic algorithm is included.

Certificate Renewal where the existing key pair is maintained and the maximum lifetime of a certificate is extended is not applied within PKIoverheid.

The time of (routine) renewal of certificates is related to the lifecycle of certificates and signing keys. For the relying party, during the term of an end user certificate, it must also be possible to verify the validity of the certificate. When an end user certificate is verified, the validity of the aforementioned certificates of issuing TSPs is also verified. Therefore the TSP certificate, the domain certificate and the root certificate will have to be valid during the course of the validity period of an end user certificate.

Once every five years, the PA will generate new signing keys (for root and domains) and issue new certificates (root certificate and domain certificates). The new signing keys replace the previous versions; the original certificates will continue to exist alongside the new certificates. The original certificates can be used to verify certificates that are issued under the original root.

The signing keys of a TSP have to be renewed at the time at which the lifespan of the parent certificate (TSP certificate, domain certificate or root certificate) expires, minus the term of validity of the end user certificate. Taking this required verification period into account, a TSP has to create new signing keys (or arrange for these to be created) and also submit a request to the PA to create the new TSP certificate.

This request is the first step of the internal procedure of TSP certificate renewal. This procedure broadly comprises the following steps:

· Submission of an application form to renew a TSP CA under the new root by the authorized representative of the TSP;

· Verification of the validity of the request by the PA;

· Validation of the data in the application form;

· Submission of the Naming Document for the new TSP CA certificate by the TSP;

· Verification of the Naming Document by the PA;

· Submission of the Certificate Signing Request (CSR) by TSP for Test TSP CA;

· Creation of a Test TSP CA certificate by the technical administrator of the root;

· Verification Test of TSP CA certificate by the PA and TSP;

· Submission of a Certificate Signing Request (CSR) by TSP for Production TSP CA;

· Instruction from the PA to the technical administrator of the root for the creation of a new TSP CA certificate;

· Execution of a creation ceremony of new TSP CA certificate by the technical administrator of the root;

· Verification by PA of new TSP CA certificate;

· Handover by PA of new TSP CA certificate to the TSP;

· Discharge of the technical administrator of the root by PA.

The request, the issuance, the adoption and the publication of the new TSP certificate follow the same steps as those taken for the original admittance of a TSP, see 4.2 to 4.5. The new signing keys replace the previous versions. The original TSP CA certificate will continue to exist for a certain period of time alongside the new TSP CA certificate.

The original certificates can be used for verification of certificates that are issued under the original TSP certificate.

4.7 Certificate Re-key

Certificate Re-key, where the existing public key of a certificate is changed, is not applied within the central hierarchy of the PKI for the government.

4.8 Certificate Modification

Certificate Modification is only applied in exceptional cases. Usually, the preference is to reissue a certificate when the content of the certificate (public key) is no longer correct.

4.9 Certificate Revocation and Suspension

Revocation of the root certificate, a domain certificate or a TSP certificate will in any cases be considered if the signing key belonging to the certificate is compromised or suspected to be compromised. The TSP is considered to be compromised if unauthorized access is gained to this signing key or when carriers of the private key are stolen or lost. To effect this, the PA keeps records of incidents that can lead to revocation of the root certificate, a domain certificate or a TSP certificate. All messages are registered by the PA and are dealt with. The Personal Data Protection Act (“Wet Bescherming Persoonsgegevens”) applies and is taken into account.

The PA considers compromise of the signing key to be an emergency. Should an emergency occur, the emergency plan will take effect and all relevant parties will immediately be informed. The emergency plan is discussed in paragraph 5.7 of this CPS.

Prior to revocation of a root certificate, a domain certificate or a TSP certificate and the keys associated with this certificate, a careful assessment process is followed. The emergency team will perform this assessment and will initiate any activities that may ensue from this, or arrange for these to be initiated.

If a TSP no longer fulfils the conditions for participation in the PKI for the government, the PA can revoke the relevant TSP certificate. The revocation of a certificate can be effectuated within one day. The PA informs the TSP prior to the certificate being revoked.

If the root certificate is revoked, the PA informs the TSPs. The revocation of the root certificate is reported in the Official Gazette (Staatscourant) and through other media where the root certificate is or shall be formally published.

In the event of the revocation of a domain certificate, the PA can inform the child CAs (TSPs).

The decision to revoke the root certificate or a domain certificate will be accompanied by a decision on whether or not a new certificate will be issued to replace the revoked certificate.

The revocation of a domain certificate or a TSP certificate always leads to ad-hoc publication of the relevant modified CRL. The revocation of certificates and the issue of CRLs takes place in accordance with a pre-prepared script. The new CRL will be published a maximum of 24 hours after revocation of a domain or TSP CA.

Certificate suspension is not supported within the PKI for the government.

4.10 Certificate Status Services

4.10.1 Operational characteristics of the Certificate Status Service

The validity of certificates can be consulted using the published CRL which is available through the electronic repository (see 2.1). For the CRLs, the PA uses the X.509 version 2 format.

As well as the publication of the CRL, the PA also offers an Online Certificate Status Protocol (OCSP) service for the G3 root certificate and the G3 domain organization services. The OCSP service is normally updated every 12 hours. An OCSP response from this service remains valid for up to 7 days. In the event of the revocation of a G3 TSP CA certificate, the OCSP service is updated ad-hoc. The OCSP service supports the GET method for requesting a response.

With regard to its CRL and OCSP services, the TSP retains appropriate server capacity, meaning a response time will be guaranteed of 10 seconds or less under normal circumstances.

During the lifetime of the aforementioned CA, the status of revoked certificates will remain available on the CRL and through OCSP.

4.10.2 Certificate Status Service availability

The CRL and OCSP are available 24 hours a day, 7 days a week.

The maximum period of time within which the availability of the revocation status information (the status of a revoked certificate) has to be restored is four hours.

4.10.3 Optional attributes of the certificate status service

No further provisions for the certificate services of TSP.

4.11 End of Subscription

If the Ministry of the Interior and Kingdom Relations decides to end the PKIoverheid service, the following actions will be undertaken:

1. All involved parties (subscribers, cross-certifying CAs, parent CAs and relying parties) of the PKIoverheid service shall be informed six months before the service ends.

2. All certificates that are issued after announcement of termination of the service has been communicated shall contain a termination date which is the same as the planned termination date of PKIoverheid.

3. When the service ends, all certificates that are still valid shall be revoked.

4. On the termination date, PKIoverheid ceases to distribute certificates and CRLs.

4.11.1 Transfer of PKIoverheid (non RFC3647)

If the Ministry of the Interior and Kingdom Relations decides to transfer the PKIoverheid service to a different organization, all involved parties (subscribers, cross-certifying CAs, parent CAs and relying parties) of the PKIoverheid service will be informed of this transfer at least 3 months in advance. The new organization will transfer the provisions from this CPS to its own CPS.

4.12 Key Escrow and Key Recovery

The PA PKIoverheid has cloned the root and domain certificates and this back-up is saved at the back-up site of PKIoverheid.

4.13 Registration of certificate holders (non RFC3647)

Unlike the TSP, the PA does not issue certificates to natural persons. A register with the personal data of certificate holders is therefore not available.

5 Management, Operational, and Physical Controls

This CPS contains a high-level description of the security measures taken by the PA.

The PA has implemented control measures in order to prevent loss, theft, damage or compromise of infrastructural assets and disruption of activities. Physical access control is among these measures. The physical set-up is made up of various layers which require separate access control, each layer requiring a higher level of security. A series of measures have also been taken to protect against fire, natural disasters, failure of supporting facilities (such as electricity and telecommunication facilities), the risk of collapse, leakages, etc.

5.1 Physical Security Controls

The secured environment of the root of the PKI for the government is set up based on the requirements formulated in the WebTrust Program for Certification Authorities, the Civil Service Information Security (Classified Information) Decree (Voorschrift Informatiebeveiliging Rijksdienst voor Bijzondere Informatie) (VIR-BI) and the standards in NIVRA document 34.

5.2 Procedural Controls

Specific processes and procedures have been implemented to handle incidents and emergencies.

The Policy Authority performs a system-wide risk analysis annually and describes the control measures taken to mitigate the risks within the system. A risk analysis is also performed when there are significant changes in internal or external factors.

In addition, every year a risk analysis is performed on the technical management of the central hierarchy of PKIoverheid.

The computer systems for production are not used for other purposes. For the testing or acceptance of new or modified software separate systems have been set up. Apart from this separation of hardware, procedures are in force that ensure that all employees respect the principle of a strict separation between the acceptance and the production environment.

The responsibilities of the PA are allocated between different functions and persons. The software checks the segregation of duties and enforces this. Generally, it is ensured that the implementation of security tasks and of regulation and verification take place independently of the implementation of production tasks. More PKI-specific measures are taken in respect of producing the key material and certificates. The PA can only generate key material and certificates in the simultaneous presence of various key holders. Each key holder only has access to part of the activation data that is required to be able to use the signing key. When producing and publishing CRLs, this so-called N out of M principle is also applied[6]. Other conditions are:

· The CA systems are stand-alone systems, without external network links;

· During operational use, CA systems are situated in a secure room that can only be accessed by persons authorized to do so;

· After use, the CA system along with all peripheral equipment and key parts are stored in a safe that is located in the aforementioned secure room;

· The CA systems are operated by a key manager, who works strictly according to the scripts and under the constant observation of a witness. Depending on the ceremony, this is an independent external witness or a representative of the PA. Any deviations from the script will be meticulously recorded;

· From the very start (retrieving CA systems and key parts) to the end (compressing CA systems and key parts), the entire ceremony is recorded and saved. The recordings are stored.

· During the ceremony, the partial keys are in the possession of the relevant key holders. The distribution of the partial keys between the key carriers is such that a specific activity cannot be carried out by the technical administrator without at least 2 civil servants being present. The N out of M principle means that several partial keys and key carriers are required.

· A request for certification (signing) is presented by the PA to the technical administrator.

5.3 Personnel Security Controls

The PA shall ensure that trusted personnel have no conflicting interests, in order to safeguard the impartiality of the activities of the PA. If this is considered necessary, the PA will only take on people in positions of trust when, based on security screening level B performed by the General Intelligence and Security Service (AIVD), a statement of no objection is issued.

The PA employs personnel who have the required expertise, experience and qualifications for the relevant positions.

5.4 Audit Logging Procedures

For the purpose of auditing, the PA records computer loggings on the changes in the systems that form part of the technical infrastructure of the top of the hierarchy and that are of importance for the trustworthiness of the services. Examples of this are creating accounts, installation of software, back-ups, closing and (re)starting the system, hardware changes and securing audit-log files.

All activities of the PA relating to generating keys and producing certificates and CRLs are logged in such a way that retrospective reconstruction of the system operations is possible.

During a TSP ceremony, when starting up the information systems, it is checked whether (unauthorized) changes have been made to these.

After each ceremony, a full back-up is made of the system and database. The back-ups are stored for a minimum period of 7 years. This only applies to the last two images from the system.

5.5 Records Archival

The PA archives relevant records relating to certificates issued by the PA, for a period of at least thirty years. This includes the documents relating to procedures carried out when creating and revoking the certificates and documents/files required in order to ascertain the validity of root certificate, domain certificates or TSP certificates at a specific point in time. The archived documents are stored by the PA in a secure manner.

The public keys of the root certificate, the domain certificates and the CRL certificates are archived as part of the corresponding certificates.

Once the validity of the TSP certificate has expired, the PA shall save, for a period of at least 7 years, all information relating to the application and revocation, if applicable, of the TSP certificate and all information used to verify the identity of the TSP, the Authorized Representative and the certificate manager.

5.6 Key Changeover

Keys of certificate holders may not be reused once the term of validity has expired, or once the corresponding certificate has been revoked. When certificates are renewed, the key pair is also renewed.

5.7 Compromise and Disaster Recovery

The PA puts provisions in place to safeguard the continuity of its services in such a way that possible disruptions are kept to a minimum. This includes maintaining critical services, including offering the revocation management service, the revocation status service and providing certificate status information through the usual channels.

The provisions that the PA has put into place include the use of redundant systems, Intrusion Detection Systems and back-ups.

In anticipation of potential emergencies that may arise within the PKI for the government, the PA has prepared an emergency plan. Described in this plan are the measures to resolve an emergency as quickly as possible. The emergency plan therefore outlines how an emergency team will immediately be convened, with certain authorities and resources, which will take appropriate action.

Several parties are active within the PKI for the government (Ministry of the Interior and Kingdom Relations, PA, TSPs and the technical administrator of the root). Any of these parties can suffer an emergency, potentially impacting the other parts of the PKIoverheid chain. To be able to act in a coordinated manner in the event of an emergency, the emergency plans of the various parties are coordinated with one another.

To be properly prepared for potential emergencies and to limit the impact of an emergency the PA's emergency plan is tested periodically, at least once a year. The coordination and communication with the involved parties from the PKIoverheid chain are then also tested.

6 Technical Security Controls

6.1 Key Pair Generation and Installation

The key pairs of the PA are generated during the various creation ceremonies. For this, only stand-alone computer systems are used. These computer systems are not connected to a network; all communication between systems takes place through media such as USB stick or smartcard. Because the generation and the use of the signing key of the PA takes place occasionally, the computer systems are only used for this purpose. For the majority of the time, the critical components of the computer systems are stored in a safe.

The signing keys of the G2 and above have the following key lengths:

TSP sub-CA certificates 4096 bit RSA keys

TSP certificates 4096 bit RSA keys

Domain certificates 4096 bit RSA keys

Root certificate 4096 bit RSA keys

6.2 Private Key Protection and Cryptographic Module Engineering Controls

The active signing keys of the PA are always located in the secure housing of a cryptographic module (HSM) which meets the following:

1. the requirements laid down in the standard FIPS PUB 140-2 level 3 or higher, or the requirements defined in standard CWA 14167-2, or;

2. a trustworthy system that (as a minimum) is certified in accordance with ISO 15408 at evaluation guarantee level EAL 4+ or equivalent security criteria.

All actions with the signing keys of the PA take place in accordance with pre-defined procedures. The persons who must be present when these actions are being performed are appointed beforehand. The signing keys of the PA can only be unlocked for use when these persons are present.

Under no circumstances are the signing keys of the PA passed on to a third party for storage.

If the signing keys are taken out of service at the end of the life time, for security reasons, these signing keys will not be archived. The signing keys are destroyed in an appropriate manner, to prevent them from being reused.

A back-up is produced of all signing keys. These back-ups are stored in a different location to the location where the operational signing keys are stored. The same security measures apply to both back-ups and operational signing keys.

6.3 Other Aspects of Key Pair Management

For certificates of the G2 hierarchy, the following term of validity applies:

TSP sub-CA certificates 12 years minus 3 days TSP certificates 12 years minus 2 days

Staat der Nederlanden <Domain> CA – G2 12 years minus 1 day

Staat der Nederlanden Root CA – G2 12 years

As from the G3 hierarchy, the following term of validity applies:

TSP sub-CA certificates 15 years minus 3 days TSP certificates 15 years minus 2 days

Staat der Nederlanden <Domain> CA –<Gen> 15 years minus 1 day

Staat der Nederlanden Root CA –<Gen> 15 years

In the hierarchies of the G3 and higher, the private keys of the Staat der Nederlanden Root and Domain CAs are used for no more than 6 years to issue TSP certificates. For the remaining 9 years of the term of validity of the relevant generation, the public key can be used to validate the underlying certificates.

Five years after creating a hierarchy, the next generation is created.

6.4 Activation data

Activation data for the information systems, such as passwords and PIN codes are, like the partial keys, stored in separate seal bags in the PKIoverheid safe.

6.5 Computer Security Controls

The computers of the PA used to perform actions with a signing key belonging to the PA can only be accessed by authorized members of staff. Software-based checks are incorporated in the systems, which are responsible for access control. The software checks the authorization of the staff member before the relevant actions can take place on the computer system. The actions performed on the computer systems are logged in such a way that, at a later stage, it can be ascertained which staff member performed the logged actions. The logs that are kept are verified periodically, at least annually, by the PA.

The computer systems of the PA referred to here are implemented in such a way that only the essential actions can be performed. All unnecessary components, such as additional software installed with the OS, are removed. The computer systems are stand-alone systems, therefore provisions relating to network security do not apply. Only the separate directory server for publishing the CRL and certificates is connected to a public network. This connection has extra security, in the form of a firewall.

Measures have also been taken to detect unwanted attempts to access the systems in a timely manner.

The PA shall ensure that the cryptographic hardware and software used by the PA to sign certificates can never be modified unnoticed. This is monitored throughout the entire lifecycle of the cryptographic hardware and software.

6.6 Life Cycle Security Controls

The hardware and software used in the central hierarchy for the key management are classified by the NBV^[7]at level ’Confidential’. If any changes are made to the information systems, another evaluation is performed.

After extensive testing, CA systems are taken in production and maintained by the technical administrator. Software updates are carefully implemented after consultation with and in the presence of the PA PKIoverheid.

6.7 Network Security Controls

The Staat der Nederlanden Root CA is offline. The Staat der Nederlanden <Domain> CA is also offline. The CRLs described in this in CPS are provisioned online by means of the Certificate Status Service. The technical administrator of the Staat der Nederlanden Root CA of Logius has taken measures to safeguard the stability, the trustworthiness and the security of the network. This includes, for example, measures to regulate data traffic and to prevent unwanted data traffic, as well as the inclusion of firewalls in order to guarantee the integrity and exclusivity of the network. Measures have also been taken to detect unwanted attempts to access the systems in a timely manner.

The Directory Service is part of the annual ETSI EN 319 411-1/2 audit. This is performed by an external IT auditor. In addition, every year the Directory Service undergoes a penetration test. This is carried out by an external IT security company.

6.8 Time-stamping

The PA does not support a timestamping service as part of its services.

6.9 Cryptographic algorithms (non RFC3647)

With trustworthiness of the PKI for the government in mind, a limited number of cryptographic algorithms are permitted within the PKI for the government. On a regular basis the PA shall check whether the standards that are applied still comply with ETSI TS 102 176-1, taking into consideration the anticipated developments. Should a switch to a different algorithm be necessary, the National Communications Security Agency (NBV-AIVD) will be asked for advice beforehand. Based on the ETSI standard, the certificate profiles included in part 3 of the Programme of Requirements state which algorithms are permitted.

7 Certificate and CRL profiles

7.1 Certificate Profile

Appendices C and D contain an overview of the content of the fields of the G2 and G3 root certificate and of the domain certificates.

7.2 CRL profiles

A CRL contains information about revoked certificates that fall within the current period of validity or of which the period of validity expired less than 6 months ago.

The CRLs comply with the X.509v2 standard for public key certificates and CRLs.

The CRL of the domain CAs is valid for one year. The CRL of the TSP CAs is valid for six months.

There is a transition period of two weeks before the CRL expires, in which a new CRL is published.

7.3 OCSP profiles

The root CA and the domain CA ‘Organization Services’ use OCSP and OCSP signing certificates. OCSP signing certificates are valid for 14 months and are re-signed annually.

The OCSP responses and OCSPSigning certificates fulfill the requirements laid down in this respect in IETF RFC 2560. OCSPSigning certificates are in line with the X.509v3 standard for public key certificates.

8 Compliance Audit and Other Assessment

8.1 Frequency and circumstances of the conformity assessment

The PA of PKIoverheid shall comply with the requirements described in the latest version of the WebTrust program for CA. To this end, the PA of PKIoverheid undergoes an annual WebTrust for CA Audit[8].

Besides the Principles and Criteria for the Audit Criteria, the PA PKIoverheid also complies with the SSL Baseline Requirements Audit Criteria of WebTrust.

The PA PKIoverheid shall actively monitor the changes in the WebTrust program for CA that affects this CPS. The PA PKIoverheid will also actively monitor changes in the Baseline Requirements of the CA / Browser Forum that affect this CPS and the Programme of Requirements of PKIoverheid. The impact of these changes on the CPS and PoR of PKIoverheid shall be assessed.

The PA PKIoverheid also conforms to established government policy in relation to information security and privacy.

8.2 Identity, qualifications of the auditor

Audits are performed by an external certified WebTrust for CAs auditor.

8.3 Topics covered by the conformity assessment

This audit determines whether the quality and the security measures of the organization that has been set up meet the stipulated WebTrust standards.

8.4 Actions based on deviations

If additional security measures are recommended, the PA shall immediately take actions to implement these measures.

8.5 Communicating the results

Through a WebTrust seal, published yearly on the Logius website, the PA PKIoverheid demonstrates that it meets the WebTrust requirements.

8.6 Admittance of TSPs to the PKI for the government

See “part 2 of the Programme of Requirements PKIoverheid”^[9]

9 Other Business and Legal Matters

9.1 Fees

The Staat der Nederlanden <Domain> CAs contain a reference to this CPS. No fee is charged for consulting these certificates or the information referred to. This applies to:

• consulting the certificates;

• consulting the revocation status information (CRLs);

• consulting the Programme of Requirements: Certificate Policies and;

• consulting this CPS.

9.2 Financial Responsibility

In terms of liability, the general rules of Dutch law apply with respect to the content and scope of the statutory obligation to pay compensation. The Ministry of the Interior and Kingdom Relations and a TSP enter into an agreement or contract concerning participation of the relevant TSP in the PKI for the government. In essence, this means that the TSP is obliged to provide services under the conditions stipulated by the Ministry of the Interior and Kingdom Relations, particularly the conditions laid down in the Programme of Requirements. In this respect, the PA is the point of contact for the TSP.

Provisions regarding the liability of the Ministry of the Interior and Kingdom Relations towards a TSP are included in an agreement or contract between the Ministry of the Interior and Kingdom Relations and the TSP. The requirements that the liability of the TSP must meet, are stated in the Programme of Requirements, part 3: Certificate Policies.

The TSP enters into agreements with subscribers and relying parties. Also laid down in these agreements is the liability of the TSP in respect of subscribers and relying parties. The requirements that this liability must meet are included in the General Provisions of the Programme of Requirements, part 3: Certificate Policies.

The Staat der Nederlanden has not taken out insurance for claims for compensation in respect of any liability.

9.3 Confidentiality of Business Information

The Policy Authority PKIoverheid handles company data confidentially. Only employees of the PA PKIoverheid have access to this data.

Company data, such as audit reports and Corrective Action Plans of TSPs will be encrypted before exchange will take place.

9.4 Confidentiality of Personal Information

Unlike the TSP, PA PKIoverheid does not issue certificates to natural persons. A register with the personal data of certificate holders is therefore not available.

9.5 Intellectual Property Rights

This CPS is the property of Logius. Unaltered copies of this CPS may be distributed and published without consent, provided that the source is quoted.

9.6 Representations and Warranties

See paragraph 9.2.

9.7 Disclaimers of Warranties

See paragraph 9.2.

9.8 Limitations of Liability

See paragraph 9.2.

9.9 Indemnities

See paragraph 9.2.

9.10 Term and Termination

This is version 4.0 of the "CERTIFICATION PRACTICE STATEMENT (CPS) Policy Authority PKIoverheid certificates to be issued by the Policy Authority of the PKI for the government", October 2016.

This CPS is valid as from the date of entry into force. The CPS is valid for the period of time that the services of the PKI for the government continue or until the CPS is replaced by a newer version. Newer versions are marked with a higher version number (vX.x). If substantial changes are made, the version number if increased by 1; if other less substantial changes are made, the version number is increased by 0.1. Newer versions are published on the following website (https://cps.pkioverheid.nl).

9.11 Individual notices and communications with participants

If TSPs have any questions, they can contact the PA PKIoverheid.

Regular communication takes place by email between the PA and the TSPs that participate in the PKIoverheid framework.

TSPs are immediately informed about the publication of a new version of the CPS or Programme of Requirements. Intended changes are also announced as soon as possible.

Besides communication with the TSPs, frequent contact also takes place with AT^[10]and the auditor(s) of the participating TSPs.

9.12 Amendments

The Ministry of the Interior and Kingdom Relations is responsible for this CPS. The Ministry has delegated this task to Logius. This also includes the approval of changes to this CPS.

Any changes not considered to be changes of an editorial nature are announced and result in a new version of the CPS. Changes of an editorial nature will not give rise to a new version of the CPS being published.

9.13 Dispute Resolution Provisions

Refer to the individual agreements between Logius PKIoverheid and TSPs.

9.14 Governing Law

Dutch law shall apply.

9.15 Compliance with Applicable Law

The PA function is performed by Logius. Logius is a digital government service and a division of the Directorate-General for Government organizations. The General Administrative Law Act^[11] applies to Logius.

Appendix A. Publication of Root Certificate announcement

Root certificate G2

As published in the Official Gazette (Staatscourant) dated Monday 15 December 2008 (no. 243, page 1).

Official publication

The Minister of the Interior and Kingdom Relations announces that, on the 26th of March 2008, a new root certificate of the PKI for the government has been created under the name

Staat der Nederlanden Root CA – G2 Certificate

This root certificate is the central part of the PKI for the government. The root certificate is the pivotal point for trust in electronic transactions from and with the government when establishing identity, indicating volition and communicating confidentially.

The root certificate holder is identified as Staat der Nederlanden Root CA – G2 (Common name), Staat der Nederlanden (Organization), NL (Country).

The serial number of the root certificate is 10000012 (hexadecimal 0098 968C).

The root certificate is valid until: Wednesday 25 March 2020 11h:03m:10s GMT.

The identification of the root certificate (the fingerprint in hexadecimal form) based on the SHA1 algorithm is: 59AF 8279 9186 C7B4 7507 CBCF 0357 46EB 04DD B716

This root certificate, the underlying documents related to this certificate and further information about this root certificate are available in digital format on the website: http://www.pkioverheid.nl/. This website provides an explanation of how the root certificate can be identified.

The Policy Authority of the PKI for the government is responsible for managing the root certificate. This organization is part of Logius, the joint maintenance organization. Logius is part of the Ministry of the Interior and Kingdom Relations.

The Ministry of the Interior and Kingdom Relations,

G. ter Horst.

Root certificate G3

Official publication

The Minister of the Interior and Kingdom Relations announces that, on the 14th of November 2013, a new root certificate of the PKI for the government has been created under the name

Staat der Nederlanden Root CA - G3

This root certificate is the central part of the PKI for the government. The root certificate is the pivotal point for trust in electronic transactions from and with the government when establishing identity, indicating volition and communicating confidentially.

The root certificate holder is identified as Staat der Nederlanden Root CA – G3 (Common name), Staat der Nederlanden (Organization), NL (Country).

The serial number of the root certificate is 10003001 (hexadecimal 00 98 a2 39).

The root certificate is valid until: Tuesday 14 November 2028 0:00:00 hours.

The identification of the root certificate (the fingerprint in hexadecimal form) based on the SHA1 algorithm is: D8EB 6B41 5192 59E0 F3E7 8500 C03D B688 97c9 EEFC.

This root certificate, the underlying documents that support this certificate and further information about this root certificate are available in digital format on the website: http://www.logius.nl/producten/toegang/pkioverheid/. This website provides an explanation of how the root certificate can be identified.

The Policy Authority of the PKI for the government is responsible for managing the root certificate. This organization is part of Logius, digital government service of the Ministry of the Interior and Kingdom Relations.

The Minister of the Interior and Kingdom Relations.

Appendix B. Procedures for the change management of the PoR PKIoverheid

Consultation structure

1. Within the PKIoverheid framework the following bodies are involved in the change management of the Programme of Requirements: The PKIoverheid Change Council and PKIoverheid Framework Council.

2. The Framework Council comprises a delegation of the PA and the TSPs that participate in the PKIoverheid framework. The Change Council is also formed by a delegation of the PA and TSPs and the opportunity is given to invite experts.

3. Auditors of TSPs that participate in the PKIoverheid framework may join in the deliberations of the Change Council and/or Framework Council as an observer. When an auditor is present, he/she will have familiarized him/herself with the change proposals and is able to at least indicate whether a new or amended standard can be audited.

4. The specific aim of these bodies is facilitate consensus on changes to the Programme of Requirements (PoR).

The Change Council congregates to discuss draft change proposals and to reach, as far as possible, consensus on the final change proposals.

The Framework Council is a platform where announcements concerning the PKIoverheid framework by the PA are made and a proposed decision is taken on the inclusion of final change proposals in the next version of the PoR, including an effective date.

5. In principle, the Framework Council is convened twice a year in relation to the publication of a new version of the Programme of Requirements of PKIoverheid.

6. In any case, the Change Council meets one month before a Framework Council meeting, but can be convened more often in order to discuss change proposals which will have a significant impact.

7. Separate meeting are organized to discuss specific subjects, which are not directly related to current PoR changes.

Decision-making

1. During the Framework Council meeting, based on a consensus, an attempt is made to take a proposed decision concerning the content and effective date of changes to the Programme of Requirements.

2. Changes to the PoR are enforced by the Ministry of the Interior and Kingdom Relations, which as the owner has ultimate responsibility for the PKIoverheid framework and makes decisions about enforcing change proposals, sometimes through an accelerated change procedure. The PA provides the owner with advice in this regard.

3. Each proposed change that has been discussed by the Framework Council or as a result of the accelerated change procedure is submitted by the PA for approval to an official appointed by the Ministry of the Interior and Kingdom Relations, along with a recommendation from the PA and the opinion of the TSPs^[12].

4. In addition, the official appointed by the Ministry of the Interior and Kingdom Relations will be informed about change proposals that have (temporarily) been revoked.

5. If there is a disagreement with the TSPs on a change proposal, the decision will be justified by the official from the Ministry of the Interior and Kingdom Relations.

6. After approval is given by the official appointed by the Ministry of the Interior and Kingdom Relations, the change will be published by the PA on the website of Logius in a way that is clearly identifiable and uses comprehensible language; also stated is when the change shall take effect.

7. In addition, the PA informs the TSP contact persons and the party that submitted the change proposal electronically and/or in writing of the decision that has been taken.

8. If there is a new version of the PoR, prior to publication a formal signature is required by both the director of Logius and the official appointed by the Ministry of the Interior and Kingdom Relations. In the event of an accelerated change procedure, approval of changes by email will suffice.

9. The official appointed by the Ministry of the Interior and Kingdom Relations reserves the right to make changes to the PoR autonomously in the context of an (imminent) incident, emergency or crisis.

Framework

1. TSPs must comply with the content and effective date of changes approved or published by the official appointed by the Ministry of the Interior and Kingdom Relations.

2. When a TSP cannot meet the effective date of a new or changed requirement, the TSP must ask for formal dispensation for this from the PA PKIoverheid.

3. A request for dispensation is formally submitted at the latest one week after the convening of the Framework Council and must be announced during the meeting.

4. Dispensation has to be requested electronically and/or in writing from the PA PKIoverheid.

5. The PA submits the proposed granting of dispensation for approval to the official appointed to that end by the Ministry of the Interior and Kingdom Relations.

6. The PA shall respond electronically and/or in writing stipulating whether the request is honored or refused. The auditor of the TSP will receive a copy of this message.

Change proposals

1. The following parties can submit a change proposal regarding a part of, or a provision in the Programme of Requirements (PoR) through the usual or accelerated change procedure:

• The Ministry of the Interior and Kingdom Relations;

• the PA PKIoverheid (PA);

• TSPs within the PKI for the government that use the PoR.

2. The PA can submit change proposals based on the input from end users or other stakeholders. This will be clearly indicated in the change request.

3. Change requests are usually approved through by the Change Council and Framework Council. If a change cannot wait until the next version of the PoR, an accelerated change procedure can be followed.

4. A change proposal can be submitted by completing the request form "Change proposal Programme of Requirements" and sending this to the PA. This form can be found on the PA's website or can be requested directly from the PA.

5. The PA handles a submitted change proposal regarding a part of or a provision in the PoR in accordance with documented internal processes. In the event of a contentual change the PA will issue a recommendation, including text proposal, impact analysis (for a transitional arrangement, effective dates and possible dispensation, etc.) and reasoning. These are submitted to the TSPs for approval.

Ordinary change procedure

1. In principle, a new version of the PoR is published twice a year. A proposed decision regarding inclusion of a new or amended requirement in the PoR is taken during the meeting of the Framework Council prior to publication.

2. A change proposal is immediately distributed by the PA amongst the TSPs and the auditors of the TSPs as soon as a draft of the change is available.

3. Change proposals are sent to the TSPs at least ten weeks before the Framework Council meets.

4. Change requests submitted after this date will not be considered for publication in the next version of the PoR, unless the PA and TSPs agree unanimously that this change can still be included.

5. TSPs have five weeks to analyze change proposals and to give feedback to the PA.

6. This feedback is discussed during the Change Council meeting prior to the meeting of the Framework Council.

7. Taking the Change Council input into consideration, change proposals are finalized.

8. The PA sets the dates for the Change and Framework Council meetings. The meetings will take place as soon as possible after the latest draft proposals for the next version of the PoR have been distributed. There will be a minimum of 4 weeks between the Change Council meeting and the Framework Council meeting.

9. The final change proposals are sent to the TSPs and the auditors no later than two weeks after the Change Council meeting, along with the agenda for the Framework Council meeting.

10. The response time of TSPs to the agenda and the final change proposals is at least one week and ends no later than one week before the Framework Council meeting.

11. TSPs are expected not to put forward new insights once the final change proposals have been completed and distributed. This is meant to prevent the PA and other TSPs being forced to take a decision during the Framework Council meeting without the possibility to carefully consider the content of the new proposal.

12. If the delegation from a TSP cannot be present during a Change or Framework Council meeting, the TSP contact person is expected to elaborate on their point of view in advance and in writing concerning the content and the effective date of changes.

13. Following the Framework Council meeting, the PoR will be published as soon as possible. The effective dates of the new or amended changes are at least four weeks after publication of the new version of the PoR.

14. The effective dates of changes are specifically included in the PoR.

I Ordinary change process in weeks

Accelerated change procedure

1. Changes are usually dealt with through the ordinary change procedure. In the event of an (imminent) incident, emergency or crisis, the official appointed by the Ministry of the Interior and Kingdom Relations can make changes autonomously. In addition, an accelerated change procedure can be followed, if it is necessary to enforce a change well before publication of a new version of the PoR.

2. Using the utmost caution the PA decides when it is necessary to follow an accelerated change procedure.

3. An accelerated change procedure entails the following process:

a) The TSPs, the auditors of the TSPs and the official appointed by the Ministry of the Interior and Kingdom Relations are informed by email of the intention of the PA to publish a change through an accelerated change procedure on the Logius website , along with the change request.

b) TSPs have at least one week to submit objections to the content and/or effective date of this change.

c) Any objections will be carefully considered by the PA PKIoverheid which, in close consultation, shall endeavor to provide sound advice.

d) The decision making process followed by the Ministry of the Interior and Kingdom Relations is described in the paragraph entitled “Decision-making”.

e) The PA publishes the change on the website and communicates this to the TSPs. The TSPs must adhere to the content and the effective date of the change published on the Logius website.

Miscellaneous

1. The PoR and the approved changes can be obtained in electronic form via the Internet on the PA's website: http://www.logius.nl/pkioverheid.

2. In the PoR, reference is made to this change procedure, which is included in the CPS of PKIoverheid.

Appendix C. Certificate profile TSP CA G3

* accessMethod

Only for Server CA certificates and optionally for Services

Other CA Certificates

**ExtendedKeyUsage

Only for Server CA certificates:

Other CA certificates:

Appendix D. Content fields G2 root certificates and domain certificates

Attribute