Certification Practice Statement of the Policy Authority PKIoverheid version 4.0 for G3 and G2 CA certificates v4.0

Table of Contents

Revision control

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 an agreements system.This system 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 Certification Service Providers (CSPs) to the PKI for the government and preparing the administration;

3. regulating and monitoring the activities of CSPs 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 Certification Service Providers (CSPs), can be admitted to the PKI for the government under certain conditions. Participating CSPs are responsible for the services within the PKI for the government. The PA oversees the trustworthiness of the entire PKI for the government¹.

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 sections 3a to e;

2. management of Object Identifiers, the unique numbers for CSPs 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 CSPs to the PKIoverheid;

9. implementation of the admission of CSPs, including creation, issuance and management of CSP CA certificates;

10. preparation concerning the revocation of CSP CA certificates;

11. implementation of the revocation of CSP CA certificates;

12. regulation of permitted CSPs;

13. preparation concerning the renewal of CSP CA certificates;

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

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

KPN BV is responsible for the technical management of The State of the Netherlands Root CA and The State of the Netherlands <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 (not RFC 3647)

The government's Public Key Infrastructure (PKI) has a structure where a central and an operational or local part of PKIoverheid are defined; 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 considered to be G2 and G3; the 'G' means 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 CSPs.

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 regulation is organized.

The CSP 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 CSP level, the CSP organization is ultimately responsible for issuing certificates.

1.2 Document name and identification

The Certification Practice Statement certificates within the PKI for the government (hereinafter referred to as CPS) provides CSPs, 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 (The State of the Netherlands Root CA) and Level 2 (The State of the Netherlands <Domain> CA).

This CPS also describes the processes and procedures for applying for, producing, issuing and revoking Level 3 <CSP 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), reference is made to the relevant various Certification Practice Statements of the PKIoverheid certification service providers

The format of this CPS is, as far as possible, in accordance with the RFC3647² standard (in full: “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework”) of the Internet Engineering Task Force.

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

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

1.2.1 Objective of CPS (not RFC 3647)

This CPS provides information to CSPs, 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 Certification Service Providers (CSPs) is also of importance. This relationship and the conditions under which CSPs can participate in the PKI for the government are broadly described.CSPs interested in participating in the PKI for the government can obtain more detailed information about this subject from the PKIoverheid Programme of Requirements section

2.

1.2.2 Relationship between CPS and CP (not RFC 3647)

The CP PoR sections 3a to e describe the minimum requirements stipulated in relation to the services of a CSP 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 (not RFC 3647)

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 sections 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, because of which it is not possible to (at the very least) fulfil the minimum requirements in this document, which is at the discretion of the PA, the provisions in the Requirements shall prevail.”

1.2.4 Certificate Policies (CPs) (not RFC 3647)

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

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

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

Section 3c – Certificate Policy for Citizen Domain;

Section 3d – Certificate Policy for Autonomous Devices Domain;

Section 3e – Certificate Policy for Server Certificates.

Section 3f – Certificate Policy for Extended Validation

Section 3g – Certificate Policy for Private Services

Section 3h – Certificate Policy for Private server certificates

Section 3i – Certificate Policy for Private Persons

This CPS only relates to CP sections 3a to e. 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 section 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 sections 3g to 3i.

1.2.4.1 Positioning Programme of Requirements (not RFC 3647)

The Programme of Requirements is at the heart 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 sections and in each section, a specific aspect of the PKI for the government is elaborated on in further detail.

1.2.4.2 Introduction Programme of Requirements (not RFC 3647)

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

1.2.4.3 Admittance to and regulation (not RFC 3647)

Section 2 describes how a CSP 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 CSPs that have been admitted.

1.3 Involved parties

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 Certification Service Provider (CSP);

4. Subscriber;

5. Certificate holder;

6. the relying party.

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

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 establishment of the infrastructure and the participation of CSPs 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³ of the PKI for public infrastructure and supervising and monitoring the work of CSPs that issue certificates under The State of the Netherlands Root CA of the PKI for the government.

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

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

The certificate holder is the holder of the private key belonging to the public key mentioned 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 CSPs. The PA issues certificates to itself (The State of the Netherlands Root CA and The State of the Netherlands <Domain> CAs) and to CSPs (CSP CA).

The relying party is the recipient of a certificate issued within the PKI for the government and acts confidentially in respect of that 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, section 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;

• CSP certificate;

• End user certificate.

The root certificate, the domain certificates and the CSP 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 CSPs. 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 CSP certificates.

1.5 Policy management

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, CSPs 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) CSP.

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: 0900-555 4555

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 Logius management 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 abbreviations

In section 4, an explanation is given regarding the definitions and abbreviations used in the Programme of Requirements.

For a list of the used definitions and abbreviations, reference is made to http://www.logius.nl/begrippenlijst.

1.7 Guarantees (not RFC 3647)

When issuing PKIoverheid certificates, the following parties are recognised:

• Subscriber;

• End user;

• Organizations that develop internet browser software;

• 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 CSP that has created a sub-CA. Neither shall these sub-CAs 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:

PKIoverheid and its certification 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 sections 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, reference is made to the relevant different Certification Practice Statements of the PKIoverheid certification service providers.

1.8 Verification of trustworthiness (not RFC 3647)

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

• Has the message been changed whilst being sent, or 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 CSP 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 CSP 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, CSP 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 (not RFC 3647)

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 CSP). The relying party can do this by assessing the Certification Practice Statement (CPS) of the CSP. The certificate refers to the CPS. To avoid a relying party having to assess every CPS of the CSPs within the PKI for the government in detail, the hierarchy of the PKI for the government is 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 CSPs 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 CSP, are described in this CPS of the PA. By assessing the CPS of the PA, the relying party can determine whether he/she trusts 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 framework consultation PKIoverheid (not RFC 3647)

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. When 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 consultation has been set up that is consulted regarding decision-making about change proposals in respect of the Programme of Requirements . Also dealt with during this consultation are 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 are attached as Annex B.

2 Publication and electronic repository responsibilities

2.1 Electronic repository

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

An admitted CSP publishes the CSP 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 CSPs.

2.2 Publication certificate information

The following certificates are published:

• The State of the Netherlands Root CA – G2;

• The State of the Netherlands Citizen CA – G2;

• The State of the Netherlands Organization CA – G2;

• The State of the Netherlands Autonomous Devices CA - G2;

• The State of the Netherlands Root CA – G3;

• The State of the Netherlands Citizen CA – G3;

• The State of the Netherlands Organization Services CA – G3;

• The State of the Netherlands Organization Person CA – G3;

• The State of the Netherlands Autonomous Devices CA – G3;

• <Name CSP> CA – G2;

• <Name CSP> 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 the revoked State of the Netherlands CA domain certificates:
  
  http://crl.pkioverheid.nl/RootLatestCRL-G2.crl
  http://crl.pkioverheid.nl/RootLatestCRL-G3.crl

• For the revoked CSP 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 (not RFC 3647)

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 (not RFC 3647)

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 included in 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 CSPs 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 CSP certificates within that domain. A domain CRL is republished every six months. A domain CRL is published ad-hoc after revocation of a CSP 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 CSP certificates in the Organization Services domain.

Support with the OCSP takes place in line with RFC2560⁵.

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 unauthorised changes being made.

In the event that system defects, or other factors that have a negative impact on the availability of the Electronic Repository arise, an appropriate set of continuity measures have been prepared to ensure that the CRL can be available once 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 Electronic 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 fulfil the X.501 name standard. The names consist of the following components:

.

For other provisions regarding the way in which identification and authentication take place within PKIoverheid, reference is made to the relevant various Certification Practice Statements of the PKIoverheid certification 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 types of names

The name of the CSP 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 Programme of Requirements, section 2 of PKIoverheid.

3.2.2 Authentication of organizational identity

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

• that the CSP is an existing organization listed in the NHR or an organisational 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;

• to check that the name of the organization and country name registered by the CSP, listed in the certificate are correct and complete and that the applicant is authorised to represent the organization;

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

Nota bene: If the participating party has existed for less than three years and does not appear in the latest version of the quoted registration sources, if required the identity and validity of the prospective CSP can be established using a parent company or core ministry that are registered in the Chamber of Commerce 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 authorised representative of the CSP using an identity document under art. 1 of the Compulsory Identification Act:

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

• a valid driving licence 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 when renewing a certificate

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

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 CSP 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 definitely came from the CSP CA.An application can be submitted in two ways:

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

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

In the second case, the PA PKIoverheid registered authorised representative of the CSP CA should also be contacted 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 CSP CA file.

3.4 Identification and authentication when a certificate is revoked

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

Identification and authentication of the party submitting the request to revoke the CSP 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 all three cases, the PA will contact the authorised representative of the CSP 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 Operational requirements in respect of the certificate cycle

4.1 Scope

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

• Root certificate;

• Domain certificate;

• CSP certificate;

• End user certificate.

The root certificate, the domain certificates and the CSP 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 CSPs.

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

4.2 Certificate Application

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

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

When CSP 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 CSP certificates are created during special creation ceremonies. A certified external IT auditor acts as witness during the creation ceremonies by The State of the Netherlands Root CA and The State of the Netherlands <Domain> CA. A certified external IT auditor is also present as witness during the creation of the CSP CAs. For every creation ceremony, a detailed manual is produced which lists all tasks to be carried out. This main purpose of this manual is to prevent any input errors during the ceremony. A creation ceremony takes place in accordance with the manual 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 for all of the listed types of certificates in a similar manner.In this case, the certificate holder is the PA or the CSP. 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 keyholders each introduce some 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 CSP must fulfil when issuing the certificates are formulated in section 3 (Certificate Policies) of the Programme of Requirements. The way in which a CSP implements these requirements must be defined by the CSP itself in a Certification Practice Statement (CPS). The description of the services by CSPs therefore falls outside the scope of the specification of this CPS.

A separate CP is not drawn up 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 Adoption

The manual associated with the creation ceremonies also contains the procedure for ascertaining the accuracy and adopting the certificates that are created. Also listed in the manual are the names of the officers involved. The PA establishes the accuracy of the certificates. The CSP then adopts the CSP certificates.

4.5 Key Pair and Certificate Usage

The State of the Netherlands Root CA, The State of the Netherlands <Domain> CAs and the CSP 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 CSPs.

4.6 Certificate Renewal

Certificates have to be renewed when (some of) the information that forms the basis of the certificate changes or is out of date. For example, if the name of a CSP shown in the certificate changes or if the strength of a cryptographic algorithm reduces and a stronger cryptographic algorithm is included.

Certificate Renewal where the existing key pair is maintained and the term of validity of the 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 government bodies is also verified. Therefore, whilst the term of validity of an end user certificate has not yet expired, the CSP certificate, the domain certificate and the root certificate have to be valid.

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 CSP have to be updated at the time at which the lifespan of the aforementioned certificate (CSP 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 CSP can create new signing keys (or arrange for these to be created) and also submit a request to the PA to create the new CSP certificate.

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

• Submission of an application form to renew a CSP CA under the new root by the authorised representative of the CSP;

• 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 CSP CA certificate by the CSP;

• Verification of the Naming Document by the PA;

• Submission of the Certificate Signing Request (CSR) by CSP for Test CSP CA;

• Creation of a Test CSP CA certificate by the technical administrator of the root;

• Verification Test of CSP CA certificate by the PA and CSP;

• Submission of a Certificate Signing Request (CSR) by CSP for Production CSP CA;

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

• Execution of a creation ceremony of new CSP CA certificate by the technical administrator of the root;

• Verification by PA of new CSP CA certificate;

• Handover by PA of new CSP CA certificate to the CSP;

• Discharge of PA to the technical administrator of the root.

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

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

4.7 Certificate Rekey

Certificate Rekey where the existing public key is changed to a certificate, 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 CSP certificate will in any cases be considered if the signing key belonging to the certificate is compromised or suspected to be compromised. This is considered to be compromised if unauthorised access is gained to this signing key or when carriers of this are stolen or lost. To effect this, the PA maintains a register of the messages that can lead to revocation of the root certificate, a domain certificate or a CSP 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 CSP 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 CSP no longer fulfils the conditions for participation in the PKI for the government, the PA can revoke the relevant CSP certificate. The revocation of a certificate can be effectuated within one day. The PA informs the CSP prior to the certificate being revoked.

If the root certificate is revoked, the PA informs the CSPs and cooperation is arranged. 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 underlying CSPs.

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 CSP 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 manual. The new CRL will be published a maximum of 24 hours after revocation of a domain or CSP CA..

Suspension of certificates will not be 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 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 updated as standard 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 CSP 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 CSP 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 CSP.

4.11 Termination

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

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

2. All certificates that are issued after termination of the service has been communicated will 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 will be revoked.

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

4.11.1 Transfer of PKIoverheid

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, higher 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 will be saved at the back-up site of PKIoverheid.

4.13 Registration of certificate holders (not RFC 3647)

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

5 Physical, procedural and personnel security

Broadly described in this CPS are 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 provided for. 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

The secured environment of the root of the PKI for the government is set up based on requirements formulated in the WebTrust Program for Certification Authorities and the requirements in 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 Security

To deal with incidents and emergencies, specific processes and procedures have been implemented.

The Policy Authority performs a system-wide risk analysis annually and describes the control measures taken to reduce 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 for the technical management of the central hierarchy of PKIoverheid.

The computer systems for production are not used for other purposes. Separate systems have been set up, the sole purpose of which is to test or accept new or modified software. Apart from this separation of hardware, procedures are in force that ensure that all employees respect the principle of a strict separation between the adoption and the production environment.

The responsibilities of the PA are allocated between different functions and persons. The software checks the segregation of functions 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 applied⁶. Other preconditions 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 authorised 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 key parts are in the possession of the relevant key holders. The distribution of the key parts 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 key parts and key carriers are required.

• A request for certification is presented by the PA to the technical administrator.

5.3 Personnel security

The PA shall ensure that personnel in positions of trust 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 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 security audits

For the purpose of audits, the PA records computer loggings with 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 CSP ceremony, when starting up the information systems, it is checked whether (unauthorised) 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 Documents Archival

The PA archives relevant documents 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 be able to find out the validity of root certificate, domain certificates or CSP 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 CSP certificate has expired, the PA has to save all information relating to applying for and revocation, if applicable, of the CSP certificate and all information used to verify the identity of the CSP, the Authorized Representative and the certificate manager, for at least 7 years.

5.6 Key Renewal

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 continuity

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 concerning the redundancy supply of systems, installing Intrusion Detection Systems and making back-ups.

To be able to anticipate 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, CSPs and the technical administrator of the root). An emergency can occur with any of these parties, which can possibly have an impact on the other parts of the PKIoverheid chain. To be able to act in the event of an emergency in a coordinated manner, 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 also tested at the same time.

6 Technical Security

6.1 Key Pair Generation and Installation

The PA's key pairs 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 PA's signing key 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:

CSP sub-CA certificates 4096 bit RSA keys

CSP 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

6.3

The PA's active signing keys 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 PA's signing keys take place in accordance with pre-defined procedures. The persons who must be present when these actions are being performed are appointed beforehand. The PA's signing keys can only be unlocked for use when these persons are present.

Under no circumstances are the PA's signing keys 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 room to the room where the operational signing keys are stored. The same security measures apply to the back-ups than those that apply to the operational signing keys.

6.4 Other aspects of key pair management

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

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

The State of the Netherlands <Domain> CA – G2 12 year minus 1 day

The State of the Netherlands Root CA – G2 12 years

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

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

The State of the Netherlands <Domain> CA –<Gen> 15 years minus 1 day

The State of the Netherlands Root CA –<Gen> 15 years

In the hierarchies of the G3 and higher, the private keys of The State of the Netherlands Root and Domain CAs are used for no more than 6 years to issue CSP 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.

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

6.5 Activation data

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

6.6 Control measures for computer systems

The PA's computers used to perform actions with a signing key belonging to the PA can only be accessed by authorised members of staff. Software-based checks are incorporated in the systems, which are responsible for access control.The software checks the authority 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 PA's computer systems referred to here are set up in such a way that only the essential actions can be performed. All redundant components in that respect, such as help programs, are dispensed with. 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 amended unnoticed. This is monitored throughout the entire lifecycle of the cryptographic hardware and software.

6.7 Life Cycle Technical Control Measures

The hardware and software used in the central hierarchy for the key management are included in the evaluation by the NBV at a strictly confidential level. If any changes are made to the information systems, another evaluation is performed.

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

6.8 Network Security

The State of the Netherlands Root CA is offline. The State of the Netherlands <Domain> CA is also offline. The CRLs described in this in CPS are online in the Certificate Status Service. The technical administrator of The State of the Netherlands 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-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.9 Registrations

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

6.10 Cryptographic algorithms (not RFC 3647)

With trustworthiness of the PKI for the government in mind, within the PKI for the government a limited number of cryptographic algorithms are permitted. Considering the anticipated developments, on a regular basis the PA shall check whether the standards that are applied still comply with ETSI TS 102 176-1. 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 section 3 of the Programme of Requirements state which algorithms are permitted.

7 Certificate and CRL profiles

7.1 Certificate Profiles

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. The content of the fields of a certificate can be displayed using viewers.

For the CRL for the G2 and G3 domain certificates and the CSP certificates, the PA uses the X.509 version 2 format for CRLs.

7.2 CRL profiles

A CRL contains information about revoked certificates that fall within the current period of validity or in relation to 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 for status control of the domain CAs is valid for one year. The CRL for status control of the CSP CAs is valid for six months.

There is a transition period of two weeks before the CRL expires, within 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 fulfil 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 Conformity assessment

8.1 Frequency and circumstances of the conformity assessment

The PA of PKIoverheid shall comply with the demands 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⁷.

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 affect 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 with established government policy in relation to information security The 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 on the Logius website, each year PA PKIoverheid demonstrates that it meets the WebTrust standards.

8.6 Admittance of CSPs to the PKI for the government

See “section 2 of the Programme of Requirements PKIoverheid”⁸

9 Other Business and Legal Matters

9.1 Fees

The State of the Netherlands <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) and;

• consulting the Programme of Requirements: Certificate Policies;

• consulting this CPS.

9.2 Financial Responsibility and Liability

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 CSP enter into an agreement or contract concerning participation of the relevant CSP in the PKI for the government. In essence, this means that the CSP 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 CSP.

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

The CSP enters into agreements with subscribers and relying parties. Also laid down in these agreements is the liability of the CSP 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, section 3: Certificate Policies.

The State of the Netherlands has not taken out insurance for claims for compensation in respect of any liability.

9.3 Confidentiality of company data

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 CSPs are encrypted before being shared.

9.4 Confidentiality of personal data

Unlike the CSP, 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 Liability and obligations

See paragraph 9.2.

9.7 Disclaimers of liability

See paragraph 9.2.

9.8 Limitations of Liability

See paragraph 9.2.

9.9 Indemnities

See paragraph 9.2.

9.10 Term of validity and dissolution CPS

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", document October 2016.

This CPS is valid as from the date of entry into force. The CSP 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 Agreements and communication between entities from the PKIoverheid hierarchy

9.12

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

Regular communication takes place by email with the contact persons of the CSPs that participate in the PKIoverheid framework.

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

As well as communication with the CSPs, frequent contact also takes place with the ACM and the auditor(s) of the participating CSPs.

9.13 Changes

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.14 Dispute Resolution Provisions

Refer to the individual agreements between Logius PKIoverheid and CSPs.

9.15 Governing Law

Dutch law shall apply.

9.16 Compliance with the relevant legislation

The PA function is performed by Logius. Logius is a digital government service and a division of the Directorate-General for Administration and Kingdom Relations. The General Administrative Law Act applies to Logius.

10 Appendix A. Wording of Root Certificate announcement

10.1 Root certificate G2

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

Official publication

10.2 Root certificate G3

Official publication

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

11.1 Consultation structure

1. The following consultations take place within the PKIoverheid framework for the change control of the Programme of Requirements: The PKIoverheid change consultation and PKIoverheid framework consultation.

2. The framework consultation comprises a delegation of the PA and the CSPs that participate in the PKIoverheid framework. The change consultation is also formed by a delegation of the PA and CSPs and the opportunity is given to invite experts.

3. Auditors of CSPs that participate in the PKIoverheid framework may join in with the change consultation and/or framework consultation as a listener. When an auditor is present, he/she will have familiarised 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 the two consultations is to agree changes to the Programme of Requirements (PoR).

   The change consultation is used to discuss draft change proposals and to reach, as far as possible, a consensus about final change proposals.

   The framework consultation is used for announcements concerning the PKIoverheid framework and to take a proposed decision about the inclusion of final change proposals in the next version of the PoR, including an effective date.

5. In principle, the framework consultation takes place twice a year in relation to the publication of a new version of the Programme of Requirements of PKIoverheid.

6. In any case, a change consultation takes place one month before the framework consultation, but can take place more often in order to discuss change proposals which will have a significant impact.

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

11.2 Decision-making

1. During the framework consultation, 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 client has ultimate responsibility for the PKIoverheid framework and makes decisions about enforcing change proposals, sometimes through an accelerated change procedure. The PA provides the client with advice in this regard.

3. Each proposed decision further to a framework consultation or 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 CSPs⁹.

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 CSPs about a change proposal, the decision will be justified by the official from the Ministry of the Interior and Kingdom Relations.

6. If 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 using comprehensible language; also stated is when the change shall take effect.

7. In addition, the PA informs the CSP 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.

11.3 Framework of standards

1. CSPs 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 CSP cannot meet the effective date of a new or changed requirement, the CSP must ask for formal dispensation for this from the PA PKIoverheid.

3. A request for dispensation is formally submitted at least one week after the framework consultation and announced during the consultation.

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

5. Granting of dispensation is submitted by the PA 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 by a copy to the auditor of the CSP in which the request is honoured or refused.

11.4 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);
   • CSPs 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 a change consultation and framework consultation. 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 deals with 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 change relating to the content, the PA will issue a recommendation, including wording proposal, impact analysis (for a transitional arrangement, effective dates and possible dispensation, etc.) and reasoning. These are submitted to the CSPs for approval.

11.5 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 included during the framework consultation prior to publication.

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

3. Change proposals are sent to the CSPs at least ten weeks before the framework consultation takes place.

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

5. CSPs have five weeks to analyse change proposals and to give feedback to the PA.

6. This feedback is included in a change consultation prior to the framework consultation.

7. Further to the change consultation, change proposals are finalised.

8. The dates for the change and framework consultations are decided on by the PA as soon as possible after the latest draft proposals for the next version of the PoR have been sent; there will be a minimum of 4 weeks between the change consultation and the framework consultation.

9. Final change proposals are sent no later than two weeks after the change consultation to the CSPs and the auditors, along with the agenda for the framework consultation.

10. The response time of CSPs to the agenda and the final change proposals is at least one week and is no more than one week for commencement of the framework consultation.

11. CSPs are not expected to put forward new insights once the final change proposals have been completed and sent. The intention is to prevent the PA and other CSPs being forced to take a decision during the framework consultation without carefully considering the content of the new proposal.

12. If the delegation from a CSP cannot be present during a change consultation or framework consultation, the CSP contact person shall be expected to explain his/her point of view beforehand and in writing concerning the content and the effective date of changes.

13. Following the framework consultation, 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.

11.6 Accelerated change procedure

1. Changes are usually dealt with through the ordinary amendment 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. The PA decides when it is necessary to follow an accelerated change procedure and, when considering this, will take the greatest possible care.

3. In terms of an accelerated change procedure, the following process is followed:

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

   2. CSPs have at least one week to submit objections to the content and/or effective date of this change.

   3. An objection will be considered by the PA PKIoverheid which, in close consultation, shall endeavour to provide sound advice.

   4. Decisions are made by the Ministry of the Interior and Kingdom Relations as described in the paragraph entitled “Decision-making”.

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

11.7 Miscellaneous

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

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

12 Appendix C. Certificate profile CSP CA G3

accessMethod

Only for Server CA certificates and optionally for Services

Other CA Certificates

ExtendedKeyUsage

Only for Server CA certificates:

Other CA certificates:

13 Appendix D. Content fields G2 root certificates and domain certificates

14 Appendix F. Content fields G3 root certificates and domain certificates