Table of Contents

1 Introduction

The Certification Practice Statement (CPS) within the Public Key Infrastructure (PKI) for the Dutch government (PKIoverheid) provides Trust Service Providers (TSPs), subscribers and relying parties with information regarding the procedures and measures taken in respect of the serices of the Policy Authority (PA) with regard to certificates issued by the following “Staat der Nederlanden” root and intermediate certificates:

The names of the root certificates contain common PKI abbreviations. G1, G2, and G3 stand for first, second, and third generation respectively, and CA stands for a Certification Authority.

The format of this CPS is, as far as possible, in accordance with the Request for Comment (RFC) 3647 standard (in full: “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework” in which X.509 refers to “X Series Recommendation on Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks”) of the Internet Engineering Task Force (IETF).

1.1 Overview

This CPS describes the processes, procedures and control measures for applying for, producing, issuing, managing and revoking issuing certificates, insofar as the PA is directly responsible for this. This means that this CPS only relates to PKIoverheid (PKIo) Level 1 (root) and Level 2 (intermediate) certificates.

This CPS also describes the processes and procedures for applying for, producing, issuing and revoking Level 3 PKIo TSP issuing 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 CPS of the PKIo TSPs. These CPS’s comply with the PKIo Certificate Policy (CP), called the PKIo Program of Requirements (PoR). The PKIo PoR describes the minimum requirements in relation to the different trust services a TSP can provide within PKIo.

The structure of the PKIoverheid production root hierarchies is as follows:

1. Root certificate Staat der Nederlanden Root CA - G3 (Publicly Trusted, in Mozilla and Microsoft Root Stores)
   1. Intermediate certificate Staat der Nederlanden Burger CA - G3 (Legacy, S/MIME Capable)
      1. TSP certificate TSP Burger CA - G3 (Legacy)
         1. End entity certificate authenticity
         2. End entity certificate non-repudiation (eSignatures)
         3. End entity certificate confidentiality
   2. Intermediate Staat der Nederlanden Autonome Apparaten CA - G3 (Legacy, S/MIME Capable))
      1. TSP certificate TSP Autonome Apparaten CA - G3 (Legacy)
         1. End entity certificate authenticity
         2. End entity certificate combination
         3. End entity certificate confidentiality
   3. Intermediate Staat der Nederlanden Organisatie Services CA - G3 (Legacy, S/MIME Capable)
      1. TSP certificate TSP Organisatie Services CA - G3 (Legacy)
         1. End entity certificate authenticity
         2. End entity certificate non-repudiation (eSeals)
         3. End entity certificate confidentiality
   4. Intermediate Staat der Nederlanden Organisatie Persoon CA - G3 (Legacy, S/MIME Capable)
      1. TSP certificate TSP Organisatie Persoon CA - G3 (Legacy)
         1. End entity certificate authenticity
         2. End entity certificate non-repudiation (eSignatures)
         3. End entity certificate confidentiality
   5. Intermediate certificate Staat der Nederlanden Citizen CA - 2023 (eIDAS/ETSI, non-S/MIME)
      1. TSP certificate TSP Citizen CA - 2023
         1. End entity certificate authenticity
         2. End entity certificate non-repudiation (eSignatures)
         3. End entity certificate confidentiality
   6. Intermediate Staat der Nederlanden Organization Services CA - 2023 (eIDAS/ETSI, non-S/MIME)
      1. TSP certificate TSP Organization Services CA - 2023
         1. End entity certificate authenticity
         2. End entity certificate non-repudiation (eSeals)
         3. End entity certificate confidentiality
   7. Intermediate Staat der Nederlanden Organization Person CA - 2023 (eIDAS/ETSI, non-S/MIME)
      1. TSP certificate TSP Organization Person CA - 2023
         1. End entity certificate authenticity
         2. End entity certificate non-repudiation (eSignatures)
         3. End entity certificate confidentiality
   8. Intermediate Staat der Nederlanden S/MIME CA - G3 2023 (S/MIME Capable, Strict profile only)
      1. TSP certificate TSP S/MIME CA - G3 2023 (Sponsor-validated, Organization-validated and Individual-validated)
         1. End entity certificate Dual-use S/MIME
2. Root Staat der Nederlanden Private Root CA - G1 (Not publicly trusted)
   1. Intermediate Staat der Nederlanden Private Services CA - G1 (S/MIME Capable)
      1. TSP certificate TSP Private Server CA - G1
         1. End entity certificate server (organization validated)
      2. TSP certificate TSP Private Organisatie Services CA - G1 (S/MIME Capable)
         1. End entity certificate authenticity
         2. End entity certificate confidentiality
   2. Intermediate Staat der Nederlanden Private Personen CA - G1 (S/MIME Capable)
      1. TSP certificate TSP Private Personen CA - G1
         1. End entity certificate authenticity
         2. End entity certificate non-repudiation (eSignatures)
         3. End entity certificate confidentiality

Figure 1 below is a visualization of these hierarchies.

Figure 1: Image containing an overview of the PKIoverheid root hierarchies (excluding TRIAL).

The structure of the PKIoverheid TRIAL root hierarchies is as follows:

1. Root certificate TRIAL PKIoverheid Root CA - G3 (Not publicly trusted)
   1. Intermediate certificate TRIAL PKIoverheid Organisatie Services CA - G3
      1. TSP certificate TRIAL TSP Organisatie Services - G3
         1. End entity certificate server
      2. TSP certificate TRIAL TSP Organisatie Services - G3
         1. End entity certificate authenticity
         2. End entity certificate non-repudiation
         3. End entity certificate confidentiality
   2. Intermediate TRIAL PKIoverheid Organisatie Persoon CA - G3
      1. TSP certificate TRIAL TSP Organisatie Persoonn CA - G3
         1. End entity certificate authenticity
         2. End entity certificate non-repudiation
         3. End entity certificate confidentiality

Figure 2 below is a visualization of this TRIAL hierarchy.

Figure 2: Image containing an overview of the PKIoverheid TRIAL root hierarchy.

1.2 Document name and identification

This document is referred to as the “CERTIFICATION PRACTICE STATEMENT (CPS) for Staat der Nederlanden Root and Intermediate certificates management and issuance by PKIoverheid”.

Currently, only an English version of this CPS is maintained published. In the event that this CPS will be translated and published in another language, care will be taken that the translation will remain faithful to the original version. In case discrepancies do appear between the English and other language versions of this document, the English version shall prevail.

Public information about the PA or PKIoverheid is available at https://www.logius.nl/pkioverheid.

1.2.1 Revisions

In 2022 several CPS documents were unified into one document. More information about revisions of those documents can be found in version 5.1 or earlier of this unified CPS or on https://cps.pkioverheid.nl on which historical versions are published. This section will only cover the revision of the current unified CPS.

Revisions for the PKIo unified CPS (CURRENT)

1.2.2 Relevant Dates

See the “Date of entry into force” column in Section 1.2.1 of this CPS. Specific dates in CPS sections always prevail over a general date.

1.3 PKI Participants

The Ministry of the Interior and Kingdom Relations (Ministerie van Binnenlandse Zaken en Koninkrijkrelaties in Dutch, or BZK abbreviated) is responsible for PKIoverheid. BZK makes decisions regarding the layout of the infrastructure and the participation of TSPs with the PKIoverheid framework. The director of Logius represents BZK in this matter.

The PA advises the director of Logius and is responsible for managing the level 1 and level 2 CAs of PKIoverheid and supervising and monitoring the work of TSPs that issue certificates to end-users.

One or more TSPs operate in each domain of PKIoverheid. Within a domain of PKIoverheid, a TSP will issue certificates to the certificate end-users.

1.3.1 Certification authorities

The PKIoverheid PA, as well as TSPs issuing end user certificates, can be regarded a Certification Authorities (CA). Both are described separately in underlying sections.

1.3.1.1 PKIo Policy Authority

The PKIoverheid PA supports the Dutch Ministry of the Interior and Kingdom Relations (BZK) in managing PKIoverheid.

The responsibilities of the PA PKIoverheid are:

1. further developing and maintaining the framework of underlying standards for PKIoverheid, the Programme of Requirements (PoR),
2. the PKIoverheid Certificate Policy (CP); assisting Trust Service Providers (TSPs) in the process of admittance to PKIoverheid and preparing the administrative handling,
3. supervising and monitoring the activities of TSPs issuing certificates for the government under the root of PKIoverheid.

The PKIoverheid PA is responsible for managing the top tiers (level 1 and 2) of the hierarchy. PKIoverheid is structured so that external organizations, the TSPs, can be admitted to PKIoverheid under certain conditions. Participating TSPs are responsible for the services for subscribers within the PKIoverheid framework. The PA supervises the TSPs, and as such ensures the trustworthiness of PKIoverheid as a whole.

In practice, this entails:

1. management of the PKIoverheid CP (Programme of Requirements);
2. management of Object Identifiers (OIDs), 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 Certificate Revocation Lists (CRLs);
5. creation and management of key pairs and the corresponding intermediate (level 2) certificates;
6. revocation of intermediate certificates and ad-hoc publication of the corresponding CRL;
7. preparing and supervising admission of TSPs to PKIoverheid (including creation, issuance and management of TSP CA certificates);
8. supervision of PKIoverheid TSPs;
9. preparation and implementation (including creation, issuance and publication) of new TSP issuing certificates;
10. preparation and implementation of revocation of TSP issuing certificates;
11. periodic and ad-hoc publication of the TSP (level 3) certificates;
12. registration and assessment of audit (ETSI/Webtrust) reports;
13. registration and assessment of (external) threats to PKIoverheid.

KPN B.V. is responsible for the technical management of all PKIoverheid root and intermediate certificates, including maintaining the corresponding Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) responders.

The PKIoverheid Policy Authority is part of Logius (https://www.logius.nl), the digital government service of BZK.

1.3.1.2 Trust Service Providers

Trust Service Providers issue end-user certificates to subscribers and as such are the contact point for most PKIoverheid related business. An up-to-date list of all PKIo Trust Service Providers, and the type(s) of certificates they are capable of issuing is available at https://cert.pkioverheid.nl.

1.3.2 Registration authorities

Registration Authority (RA) responsibility for level 1, level 2 and level 3 CAs has been delegated by BZK to the PA PKIoverheid. As such, the PA PKIoverheid is responsible for identification and registration of the TSPs and their associated key personell. For more information, see section 3.

1.3.3 Subscribers

Due to the fact that the PA PKIoverheid only issues CA certificates to TSPs (which will be referred to as “TSP Issuing Certificates” in the rest of this document), they act as “subscribers” for the purpose of this document. All requirements and responsibilities of the TSPs are detailled in the CP (“Programme of Requirements”) PKIoverheid. To legally enforce the CP, a separate contract is drafted and signed by the parties involved. For details regarding agreement between end-users and TSPs, please refer to the relevant CPS of the TSP in question.

1.3.4 Relying parties

The relying party is the recipient of a certificate issued within PKIoverheid 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.

1.3.5 Other participants

Other participants in PKIoverheid are:

1. The Ministry of the Interior and Kingdom Relations (“Ministerie van Binnenlandse Zaken en Koninkrijkrelaties” in Dutch, or BZK abbreviated): This ministry is responsible for PKIoverheid. It makes decisions regarding the layout of the infrastructure and the participation of TSPs with the PKIoverheid framework. The director of Logius represents the Ministry of the Interior and Kingdom Relations in this matter.
2. The Dutch Authority for Digital Infrastructure (“Rijksinspectie Digitale Infrastructuur” in Dutch, or RDI abbreviated): The RDI is the Dutch National Accreditation body for European Union regulation 910/2014 on electronic IDentification, Authentication and trust Services (eIDAS) Qualified TSPs, as wel as a regulatory body for the supervision of TSPs operating in the Netherlands.
3. The National Cyber Security Centre (“Nationaal Cyber Security Centrum” in Dutch, or NCSC abbreviated): The NCSC advises on certificate usage within the Dutch government. The NCSC acts as CSIRT (“Computer Security Incident Response Team”) for the Dutch Government.

1.4 Certificate Usage

1.4.1 Permitted Certificate Usage

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

1. Root certificate;
2. Domain certificate;
3. TSP certificate;
4. 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 in different domains and with different purposes:

• Domain Organization Person:
  • authenticity;
  • non-repudiation;
  • confidentiality;
• Domain Organization Services:
  • authenticity;
  • non-repudiation;
  • confidentiality;
• Domain Citizen:
  • authenticity;
  • non-repudiation;
  • confidentiality;
• Domain Autonomous Devices:
  • authenticity;
  • confidentiality;
  • combination;
• Domain Private Services:
  • authenticity;
  • confidentiality;
  • server authentication;
• Domain Private Person:
  • authenticity;
  • non-repudiation;
  • confidentiality;
• Domain S/MIME:
  • sponsor-validated, strict;
  • organization-validated, strict;
  • individual-validated, strict.

1.4.2 Prohibited Certificate Usage

Certificates issued under this CPS may not be used other than as described in section 1.4.1.

1.5 Policy Administration

In addition to this CPS there are two additional PKIo documents which need to be publicly disclosed and require an effective administrative process:

1. the Program of Requirements for PKIoverheid TSPs, and
2. the Registration of PKIoverheid OIDs.

Although not strictly policy documents, the administration of these documents will also be described in this section because of their equal importance.

1.5.1 The organization responsible for managing policies

The Ministry of the Interior and Kingdom Relations is responsible for all PKIoverheid policy documents. The Ministry has delegated this task to Logius.

1.5.2 Contact information

In case of any questions or issues with PKIoverheid end-user certificates (level 4), the TSP which issued the end-user certificate should be contacted (contact details are found in their respective CPS).

In case of any questions or issues relating to the Root CA (level 1), Domain CA (level 2), TSP CA (level 3), their associated OCSP responders and/or CRLs the reporting party can contact Logius through the contact information below.

The Logius 24/7 Service Center should also be contacted if assistance is needed for investigative reports or revocaton requests. Additional information on the revocation procedure can be found in Section 4.9.3 of this CPS.

1.5.3 The person determining policy documents suitability for Certificate Policies

The PA PKIoverheid does not have its own general Certificate Policy. For publicly trusted roots the CA/B Forum S/MIME Baseline Requirements document applies. The PA determines if changes in the PKIoverheid policies are needed after updates to the CA/B Forum S/MIME Baseline Requirements.

1.5.4 Policy approval procedures

The policy approval procedure differs per policy document. The PA of PKIoverheid is entitled to change or to add to this CPS. However, the management of Logius is responsible for both acknowledging the procedure described in paragraph 9.12 is followed accurately, and the ultimate approval of this CPS. Only in case of editorial changes the head of the PA PKIoverheid can approve a new version of the CPS for publication.

Changes to the Registration of PKIoverheid OIDs can be approved by the PA PKIoverheid.

For the Programme of Requirements the procedure outlined in section 9.12 is followed. Initial approval of the PoR is given by the PA PKIoverheid. Final approval is needed from the Ministry of the Interior and Kingdom Relations before a new version can be formalized and published.

1.6 Definitions and abbreviations

1.6.1 Definitions

Definitions used in this CPS and the Programme of Requirements are listed in the PKIoverheid PoR, which can be found at https://www.logius.nl/english/pkioverheid.

1.6.2 Acronyms

Acronyms used in this CPS and the Programme of Requirements are listed in the PKIoverheid PoR, which can be found at https://www.logius.nl/english/pkioverheid.

2 Publication and electronic repository responsibilities

All information listed in sections 2.1 and 2.2 is available 24x7 except in cases of (unscheduled) maintenance.

2.1 Electronic repository

PKIoverheid information is published in the following locations:

• this CPS is published on the PKIoverheid website https://cps.pkioverheid.nl;
• the PKIoverheid Programme of Requirements is published on https://por.pkioverheid.nl;
• the PKIoverheid OID Registration is published on https://oid.pkioverheid.nl;
• TSP CPSs, issued certificates and Certificate Revocation Lists are published on the TSP websites.

2.2 Publication certificate information

PKIoverheid certificate information is published in the following locations:

• Official notifications of both new PKIoverheid Public and Private root certificates are published in the Official Gazette (Staatscourant);
• The PKIoverheid root, intermediate, and TSP issuing certificates are published on the PKIoverheid website https://cert.pkioverheid.nl;
• The PKIoverheid Certificate Revocation Lists for its intermediate certificates and the TSP issuing certificates are published on the PKIoverheid website https://crl.pkioverheid.nl;
• OCSP for PKIoverheid G3 intermediate CAs can be found at http://rootocsp-g3.pkioverheid.nl;
• OCSP for PKIoverheid G3 Organization Services/Server TSP CAs can be found at http://domorganisatieservicesocsp-g3.pkioverheid.nl).

2.3 Time or frequency of publication

PKIoverheid information is published with the following frequency:

• a new version of this CPS is published at least once a year;
• a new version of the PKIoverheid Programme of Requirements normally is published once or twice a year;
• new versions of the OID Registration document are published when needed;
• the PKIoverheid product page on the Logius website is updated when needed;
• TSP CPSs, issued certificates and Certificate Revocation Lists publication frequencies can vary per TSP and are described in their own CPSs;
• the CRL for PKIoverheid intermediate certificates is (re)published annually, or after revocation of an intermediate certificate, whichever is earlier;
• OCSP Responders update their information at least every twelve months and always within 24 hours after revoking an Intermediate or TSP Issuing Certificate.

2.4 Access controls to publication

Published PKIoverheid information is public in nature and freely accessible.

Write access to PKIoverheid information is limited to authorized personnel only:

• only employees of the Logius Communication team have write access to the public repository of the PKIoverheid Programme of Requirements and OID Registration documents;
• only the Logius PKIoverheid team has write access to the development environment for the PKIoverheid Programme of Requirements, OID Registration, and CPS documents;
• only the Operations team has write access to the public repository of the CPS, certificate, and CRLs;
• only the Operations team has write access to the OCSP Responder environments.

3 Identification and Authentication

3.1 Naming

3.1.1 Types of names

All PKIoverheid Root, Intermediate, and TSP certificates contain a sequence of three RelativeDistinguishedName fields in both issuer and subject fields, each containing one of the following attribute types:

• countryName
• organizationName
• commonName

Only the subject field in TSP certificates under both the PKIoverheid G3 and Private roots contain an additional RelativeDistinguishedName field with attribute type:

• organizationIdentifier

For name types in PKIoverheid end user certificates, please refer to the relevant Certification Practice Statements of the PKIoverheid TSPs.

All name types in PKIoverheid certificates adhere to the X.520 attribute naming scheme published by the International Telecommunication Union - Telecommunications sector (ITU-T).

3.1.2 Need for names to be meaningful

Names in subject and issuer fields need to be meaningful and need to uniquely identify subject and issuer respectively.

3.1.3 Pseudonyms

Within PKIoverheid no certificates are issued with pseudonimized or anonimized data in name attributes.

3.1.4 Rules for interpreting various name forms

The attribute types in the RelativeDistinguishedName fields in both the issuer and subject fields of PKIoverheid Root, Intermediate, and TSP certificates must be interpreted in the following way:

• countryName: Contains the two-letter ISO 3166-1 (the country code standard by the International Standardization Organization) country code associated with the country of incorporation of the issuer- or subject-organization, as can be found in Dutch National Trade Register (Kamer van Koophandel or a law, deed of incorporation or a general governmental decree.
• organizationName: Contains the exact organization name of the issuer or subject, as can be found in a Chamber of Commerce’s Trade Register or a law, deed of incorporation or a general governmental decree.
• commonName: Contains the common name of a certificate, conforming to PKIoverheid naming standards, but usually incorporating the organization name of the subject, a meaningful certificate identifier, and a generation or year identifier.
• organizationIdentifier: Contains the respective organization’s identification number from the Dutch National Trade Register following the semantics of ETSI EN 319 412-1 section 5.1.4

3.1.5 Uniqueness of names

All PKIoverheid certificates contain a subject and issuer field which can be used to uniquely identify the subscriber as subject or issuer respectively. However, in historic cases the subject:commonName field does not always uniquely identify the certificate itself.

3.1.6 Recognition, authentication and role of trademarks

All organizationName attributes in PKIoverheid Root, Intermediate and TSP certificates are exact copies from either the Dutch Trade Register of the Chamber of Commerce, or from the Staatsalmanak. Both are reliable data sources obliged by law to perform strong recognition, authentication and trademark checks. Correctness of this information is therefore assumed by the PKIoverheid PA.

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.

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, or if a government organization is not listed in the NHR, the Staatsalmanak 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.) which 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 registration sources listed above, the identity and validity of the prospective TSP may be established using a parent company or ministry that is registered in the NHR or the Staatsalmanak.

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, limited to the following documents:

• a valid travel document referred to in the Passport Act (“Paspoortwet” in Dutch);
• a valid driving license issued on the basis of the Road Traffic Act (Wegenverkeerswet), under article 107 of the Road Traffic Act (“Wegenverkeerswet” in Dutch) 1994.

3.2.4 Non-verified subscriber information

No stipulation.

3.2.5 Validation of authority

The PKIoverheid PA maintains an authorization list with contacts per PKIoverheid TSP. This authorization list recognizes the following general roles:

1. Operational contact;
2. Authorized signatory.

A TSP has the possibility to split up their operational contact in two or more different specialized roles:

1. General contact, and
2. Incident contact, and/or
3. Emergency contact, and/or
4. RFC discussion contact, and/or
5. RFC approval contact, and/or
6. Contact for penetration testing.

Initial contacts per TSP have to be approved by the authorized signatory and communicated through a verified method of communication. Consecutive changes may be approved by people within the same role, again through a verified method of communication.

An authorized signatory has to be listed as Director in the National Trade Register (NHR). When a TSP is a government agency without an entry in the NHR, the authorized signatory has to be at least equal to the role of Director in the Staatsalmanak.

Note: Per TSP only authorized signatories can request new issuing certificates or revocation of issuing certificates.

3.2.6 Criteria for interoperation

Cross-signing of certificates is not allowed within PKIoverheid.

3.3 Identification and authentication for Re-Key Requests

3.3.1 Identification and authentication for routine re-key

Only TSP employees with the role of signed signatory in the PKIoverheid authorization list are authorized to commit re-key requests for the TSP in question. For PKIoverheid root or intermediate certificates this can only be done by the PKIoverheid Policy Authority.

Re-key requests by TSPs always need to be signed by the TSP’s signed signatory as listed in the PKIoverheid authorization list. For PKIoverheid root or intermediate certificates the requests have to be signed with a qualified signature by the PKIoverheid Policy Authority.

3.3.2 Identification and authentication for re-key after revocation

The same procedure applies as for routine re-key. Therefore see Section 3.3.1.

3.4 Identification and authentication for Revocation Requests

Only TSP employees with the role of signed signatory in the PKIoverheid authorization list are authorized to perform Revocation requests for the TSP in question. For PKIoverheid intermediate certificates this can only be done by the PKIoverheid Policy Authority.

Revocation requests by TSPs always need to be signed by the TSP’s signed signatory as listed in the PKIoverheid authorization list. For PKIoverheid intermediate certificates the requests have to be signed with a qualified signature by the PKIoverheid Policy Authority.

4 Certificate Life-Cycle Operational Requirements

4.1 Certificate Application

4.1.1 Who can submit a certificate application

PKIoverheid TSPs can submit applications for TSP issuing certificates; the PKIoverheid PA can submit applications for PKIoverheid root or intermediate certificates. Only TSP employees with the role of signed signatory in the PKIoverheid authorization list can submit certificate applications.

4.1.2 Enrollment process and responsibilities

Certificate proposals for new TSP issuing certificates need to be electronically submitted to the PKIoverheid PA using a template provided by the PKIoverheid team, and signed by TSP signed signatory. A Certificate Signing Request (CSR) has to be provided with the template.

Certificate proposals for new root or intermediate certificates can be submitted by the PKIoverheid PA itself.

4.2 Certificate application processing

4.2.1 Performing Identification and Authentication Functions

Signatures of submitted certificate proposals are verified, and its signers are checked against the list of authorized signed signatories.

Submitted subject data fields are checked against qualified data sources. Validation will be performed no longer than 2 months prior to issuing of the certificate.

4.2.2 Approval or Rejection of Certificate Applications

Certificate applications which do not pass the identification and authentication checks listed in Section 4.2.1 will be rejected.

For certificate applications which pass the identification and authentication checks first a naming document is created for a test key ceremony producing a test certificate.

In case of a test Root certificate or Intermediate certificate the PKIoverheid team itself performs tests to verify the contents of the certificate. In case of a TSP Issuing certificate both the TSP and the PKIoverheid team verify its contents. If the content of the certificate is agreed upon to be correct, a production naming document will be created.

4.2.3 Time to Process Certificate Applications

There will be at least one month between Certificate Application and the execution of the production key ceremony. This time will be taken to check the input, verify the request and execute a test ceremony. Production key ceremonies normally only take place in one of the allotted monthly key ceremony slots.

4.3 Certificate issuance

4.3.1 CA actions during certificate issuance

PKIoverheid root, intermediate, and TSP issuing certificates are created during special creation ceremonies. For every key ceremony, a detailed script is produced which lists all tasks to be carried out. The main purpose of this script is to prevent any input errors during the ceremony. CA certificate creation ceremonies takes place in the presence of witnesses on behalf of Logius, including an internal or external (Webtrust) auditor, except for issuances under the PKIoverheid TRIAL root. The identity of all persons present is verified using the valid documents referred to under article 1 of the Compulsory Identification Act (“Wet op de identificatieplicht” in Dutch) with the exception of Key Management team members who are allowed to use the company identity card for this.

All ceremonies follow these general steps:

1. Accessing the secure room and retrieving the components needed to start up the relevant environment
2. Unpacking the components while checking serial numbers of seal bags and setting up the computer system,
3. activating the Hardware Security Module (HSM), with enforced multi person access control, where several security key guardians each introduce part of the necessary security key access,
4. generating the key pairs (only applicable to root and intermediate certificates),
5. generating certificates for each key pair,
6. dismantling the computer system, and
7. securing the computer system and the critical components.

Public keys for TSP issuing certificates are provided by the TSP itself through a CSR, communicated in a trustworthy manner. Operations on both level 1 (Root CA) and level 2 CA are performed only by authorized Key managers witnessed by Logius and/or the Qualified auditor. See also Section 5.2.2

4.3.2 Notification to subscriber by the CA of issuance of Certificate

TSP issuing certificates are sent to the TSP by the PKIoverheid PA in a trustworthy manner. This communication is regarded as an official notification.

In case of a root or intermediate certificate, no additional notification is needed.

4.4 Certificate acceptance

4.4.1 Conduct constituting certificate acceptance

In case of Root certificates and Intermediate certificates, if no issues are found within two weeks acceptance of is formalized by a letter signed by the PKIoverheid PA sent to the PKIoverheid Key Management team.

In case of TSP Issuing certificates, delivery of the certificate to the TSP is accompanied by an acceptance letter which the TSP has to sign and return to the PKIoverheid PA within two weeks when no issues are found. The PKIoverheid PA will forward this letter to the PKIoverheid Key Management (KM) team.

4.4.2 Publication of the certificate by the CA

All issued PKIoverheid root, intermediate, and TSP issuing certificates are published on https://cert.pkioverheid.nl/. In addition to this, the most relevant attributes of all PKIoverheid root certificates (excluding TRIAL root certificates) are also published in the Official Gazette (Staatscourant).

4.4.3 Notification of certificate issuance by the CA to other Entities

All PKIoverheid TSPs will be notified by E-mail by the PKIoverheid PA after the creation of a new PKIoverheid Root or Intermediate certificate.

4.5 Key Pair and Certificate Usage

4.5.1 Subscriber private key and certificate usage

PKIoverheid root, intermediate, and TSP issuing certificates are used for verifying the issuer’s signature on a subject’s certificate.

Private keys corresponding to the public keys in PKIoverheid root, intermediate, and TSP issuing certificates, are used for signing:

1. certificates issued by those certificates,
2. OCSP-signing certificates (only if an OCSP responder is used for those certificates), and
3. CRL responses on certificates issued by those certificates.

4.5.2 Relying party public key and certificate usage

No stipulation.

4.6 Certificate renewal

4.6.1 Circumstance for certificate renewal

Under normal operational circumstances PKIoverheid does not support certificate renewal. However, under exceptional circumstances and only after extensive consideration by the PKIoverheid PA and deliberation with affected TSP(s) and BZK certificate renewal may be performed. If such case arises, relevant documentation will be made available upon request.

4.6.2 Who may request renewal

For certificate renewal the same rules apply as for certificate application (see Section 4.1.1.

4.6.3 Processing certificate renewal requests

For the processing of certificate renewals the same rules apply as for processing of certificate applications (see Section 4.2).

4.6.4 Notification of new certificate issuance to subscriber

For the notification of renewed certificate issuances the same process applies as for notification of certificate issuances after application (see Section 4.3.2.

4.6.5 Conduct constituting acceptance of a renewal certificate

For the acceptance of renewed certificate issuances the same rules apply as for the acceptance of certificate issuances after application (see Section 4.4.1).

4.6.6 Publication of the renewal certificate by the CA

For the publication of renewed certificate issuances the same rules apply as for the acceptance of certificate issuances after application (see Section 4.4.2).

4.6.7 Notification of certificate issuance by the CA to other entities

For the notification to other entities of renewed certificate issuances the same rules apply as for notification to other entities of certificate issuances after application (see Section 4.4.3).

4.7 Certificate re-key

Under normal operational circumstances PKIoverheid does not support replacing the public key in an existing certificate (also known as certificate re-key). However, under exceptional circumstances and only after extensive consideration by the PKIoverheid PA and deliberation with affected TSP(s) and BZK certificate re-key may be performed. If such case arises, relevant documentation will be made available upon request.

4.7.1 Circumstance for certificate re-key

Certificate re-key may only be performed when included information in a certificate changes or is out of date. Examples are a change in the name of a TSP as included in the certificate, or if the strength of the key generation algorithm is outdated and deemed insufficient thus needing a new stronger key.

4.7.2 Who may request certification of a new public key

For certificate re-key the same rules apply as for certificate application (see Section 4.1.1.

4.7.3 Processing certificate re-keying requests

For the processing of certificate re-keys the same rules apply as for processing of certificate applications (see Section 4.2).

4.7.4 Notification of new certificate issuance to subscriber

For the notification of re-keyed certificate issuances the same process applies as for notification of certificate issuances after application (see Section 4.3.2.

4.7.5 Conduct constituting acceptance of a re-keyed certificate

For the publication of re-keyed certificate issuances the same rules apply as for the acceptance of certificate issuances after application (see Section 4.4.2).

4.7.6 Publication of the re-keyed certificate by the CA

For the publication of re-keyed certificate issuances the same rules apply as for the acceptance of certificate issuances after application (see Section 4.4.2).

4.7.7 Notification of certificate issuance by the CA to other entities

For the notification to other entities of re-keyed certificate issuances the same rules apply as for notification to other entities of certificate issuances after application (see Section 4.4.3).

4.8 Certificate modification

Under normal operational circumstances PKIoverheid does not support certificate Modification. However, under exceptional circumstances and only after extensive consideration by the PKIoverheid PA and deliberation with affected TSP(s) and BZK certificate modification may be performed. If such case arises, relevant documentation will be made available upon request.

4.8.1 Circumstance for certificate modification

Certificate modification may only be performed when included information in a certificate changes or is out of date. Examples are a change in the name of a TSP as included in the certificate, or if the strength of the key generation algorithm is outdated and deemed insufficient thus needing a new stronger key.

4.8.2 Who may request certificate modification

For certificate modification the same rules apply as for certificate application (see Section 4.1.1.

4.8.3 Processing certificate modification requests

For the processing of certificate modification the same rules apply as for processing of certificate applications

4.8.4 Notification of new certificate issuance to subscriber

For the notification of modified certificate issuances the same process applies as for notification of certificate issuances after application (see Section 4.3.2.

4.8.5 Conduct constituting acceptance of modified certificate

For the acceptance of modified certificate issuances the same rules apply as for the acceptance of certificate issuances after application (see Section 4.4.2).

4.8.6 Publication of the modified certificate by the CA

For the publication of modified certificate issuances the same rules apply as for the acceptance of certificate issuances after application (see Section 4.4.2).

4.8.7 Notification of certificate issuance by the CA to other entities

For the notification to other entities of modified certificate issuances the same rules apply as for notification to other entities of certificate issuances after application (see Section 4.4.3).

4.9 Certificate revocation and suspension

Root certificates cannot be revoked, and have to be removed from trusted root stores instead. Circumstances for removal from trust stores and revocation are the same.

4.9.1 Circumstances for revocation

For events listed in Section 4.9.1.2 of the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates the PA PKIoverheid SHALL revoke CA certificates when applicable.

To elaborate a more comprehensive outline of reasons for revocation and corresponding cRLReason codes which have to be used in CRL’s or OCSP responses is listed below.

• Compromised Private Key: [1] keyCompromise
• Compromised Private Key of CA: [2] cACompromise
• Changed affiliation: [3] affiliationChanged
• Certificate superseded: [4] superseded
• Cessation of operation: [5] cessationOfOperation
• Privilege withdrawn: [9] privilegeWithdrawn

Compromised Private Key:

The revocation reason keyCompromise [1] may only be used only in combination with the revocation of PKIoverheid OCSP-Signing certificates when one or more of the following occurs:

• the PKIoverheid PA obtains verifiable evidence that the private key corresponding to the public key in a certificate suffered a key compromise;
• the PKIoverheid PA is made aware of a demonstrated or proven method that exposes the private key corresponding to the public key in a certificate to compromise;
• there is clear evidence that the specific method used to generate the private key corresponding to the public key in a certificate was flawed; or
• the PKIoverheid PA is made aware of a demonstrated or proven method that can easily compute the private key based corresponding to the public key in a certificate (such as a Debian weak key, see https://nvd.nist.gov/vuln/detail/cve-2008-0166).

When the PA obtains verifiable evidence of private key compromise for a certificate whose CRL entry has a reasonCode extension with a non-keyCompromise reason, the PA will update the CRL entry to enter keyCompromise as the revocation reason in the reasonCode extension. Additionally, the PKIoverheid PA will update the revocation date in a CRL entry when it is determined that the private key of the certificate was compromised prior to the revocation date that is indicated in the CRL entry for that certificate.

Otherwise, the keyCompromise revocation reason will not be used.

Compromised Private Key of CA:

The revocation reason caCompromise [2] is used in combination with PKIoverheid Intermediate certificates or TSP Issuing certificates when one or more of the following occurs:

• the PKIoverheid PA obtains verifiable evidence that the private key corresponding to the public key in a certificate suffered a key compromise;
• the PKIoverheid PA is made aware of a demonstrated or proven method that exposes the private key corresponding to the public key in a certificate to compromise;
• there is clear evidence that the specific method used to generate the private key corresponding to the public key in a certificate was flawed;
• the PKIoverheid PA is made aware of a demonstrated or proven method that can easily compute the private key based corresponding to the public key in a certificate (such as a Debian weak key, see https://nvd.nist.gov/vuln/detail/cve-2008-0166); or
• after the request by a TSP for this reason the PKIoverheid PA revokes the TSP’s Issuing certificate.

When the PA obtains verifiable evidence of private key compromise for a certificate whose CRL entry has a reasonCode extension with a non-caCompromise reason, the PA will update the CRL entry to enter caCompromise as the revocation reason in the reasonCode extension. Additionally, the PKIoverheid PA will update the revocation date in a CRL entry when it is determined that the private key of the certificate was compromised prior to the revocation date that is indicated in the CRL entry for that certificate.

Otherwise, the keyCompromise revocation reason will not be used.

Changed affiliation:

The revocation reason affiliationChanged [3] is used in combination with PKIoverheid TSP Issuing certificates to indicate that the TSP’s name or other subject identity information in the certificate has changed, but there is no cause to suspect that the certificate’s private key has been compromised. Unless the caCompromise revocation reason is being used, the revocation reason affiliationChanged is used when:

• the TSP has requested that their certificate be revoked for this reason; or
• the PKIoverheid PA has replaced the certificate due to changes in the certificate’s subject information and the PA has not replaced the certificate for the other reasons: keyCompromise, superseded, cessationOfOperation, or privilegeWithdrawn.

Otherwise, the affiliationChanged revocation reason is not used.

Certificate superseded:

Unless the caCompromise or keyCompromise revocation reason is used, the revocation reason superseded [4] is used in combination with PKIoverheid Intermediate certificates, TSP Issuing certificates, or OCSP-Signing certificates if:

• the TSP has requested that its TSP Issuing certificate be revoked for this reason; or
• the PKIoverheid PA has revoked the certificate due to validation or compliance issues other than those related to caCompromise, keyCompromise or privilegeWithdrawn.

Otherwise, the superseded revocation reason will not be used.

Cessation of operation:

Unless the caCompromise revocation reason is being used, the revocation reason cessationOfOperation [5] is used in combination with TSP Issuing certificates when:

• the subscribing TSP has requested that their certificate be revoked for this reason; or
• the PKIoverheid PA has received verifiable evidence that the subscribing TSP has stopped its Trust Services or has stopped doing business in its entirety.

Otherwise, the cessationOfOperation revocation reason will not be used.

Privilege withdrawn:

Unless the caCompromise revocation reason is being used, the revocation reason privilegeWithdrawn [9] is used in combination with TSP Issuing certificates when:

• the PKIoverheid PA obtains evidence that the certificate was misused;
• the PKIoverheid PA is made aware that the TSP has violated one or more of its material obligations under the PKIoverheid Program of Requirements or Contract;
• the PKIoverheid PA is made aware of a material change in the information contained in the certificate;
• the PKIoverheid PA determines or is made aware that any of the information appearing in the certificate is inaccurate; or
• the PKIoverheid PA is made aware that the original certificate request was not authorized and that the TSP does not retroactively grant authorization.

Otherwise, the privilegeWithdrawn revocation reason will not be used.

4.9.2 Who can request revocation

The PKIoverheid PA can request PKIoverheid Key Management to revoke intermediate and/or TSP issuing certificates.

TSP signed signatories can request revocation of their issuing certificates.

Third parties may request Certificate revocation for problems related to fraud, misuse, or compromise.

4.9.3 Procedure for revocation request

During Dutch office hours revocation requests will be directed to the relevant PA employee. Outside of Dutch office hours an incident manager will triage the request and take appropriate action. In both cases additional information about a problematic report may be provided via email to the address listed in Section 1.5.2.

Certificate revocation requests must identify the entity requesting revocation, specify the reason for revocation, and include supporting evidence when applicable.

In case of major incidents which require distrust of a root certificate or revocation of a level 2 intermediate CA, a careful assessment process is followed. The incident handling team will perform this assessment and will initiate any activities that may ensue from this.

In case of new intermediate or issuing CAs having superseded existing CAs, cessation of operation or other non-emergency reasons the PA will execute this assessment themselves.

Prior to distrusts or revocations, all PKIoverheid TSPs who are affected by this will be informed.

4.9.4 Revocation request grace period

No stipulation.

4.9.5 Time within which CA must process the revocation request

The time within which PKIoverheid must process the revocation request differs per CA type:

• For publicly trusted CAs where revocation is deemed neccessary due to reasons listed in either applicable browser or Baseline Requirements the PA PKIoverheid will aim to process a revocation within the time indicated in those requirements.
• For private CAs, other non-publicly trusted CAs or publicly trusted CAs where revocation includes the reasonCode cessationOfOperation or superseded the PA will include the revocation request in the next planned key ceremony, unless more inmmediate action is deemed necessary in which case an ad hoc key ceremony is performed in which the certificate is revoked.

When receiving a Certificate Problem Report the PA aims to investigate and reply to both submitter of a Certificate Problem Report and Subject CA within 24 hours indicating any preliminary findings.

4.9.6 Revocation checking requirement for relying parties

No stipulation.

4.9.7 CRL issuance frequency

A new CRL for intermediate and TSP issuing certificates will be issued once every 364 days, or when a revocation request has been processed, whichever comes first.

4.9.8 Maximum latency for CRLs

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.

4.9.9 On-line revocation/status checking availability

In addition to CRLs, the PA PKIoverheid also provides certificate status information via OCSP in accordance with RFC 6960. OCSP responses are signed by the Private Key of an OCSP-Signing Certificate for an OCSP responder designated by the PA PKIoverheid. These certificates are issued by the same CA that issued the CA certificate that is being checked.

4.9.10 On-line revocation checking requirements

PKIoverheid OCSP responders support the HTTP GET method, as described in RFC 6960.

The PKIoverheid OCSP responder updates its information

1. at least once every twelve months, and
2. within 24 hours after revoking a subordinate certificate.

If a PKIoverheid OCSP responder receives a request for the status of a certificate serial number that is “unused”, then the responder does not respond with a “good” status.

PKIoverheid Key Management monitors its OCSP responders for requests for “unused” serial numbers as part of its security response procedures.

4.9.11 Other forms of revocation advertisements available

No other form of revocation advertisement is available.

4.9.12 Special requirements related to key compromise

See Section 4.9.1.

4.9.13 Circumstances for suspension

Suspension of certificates is not supported within PKIoverheid.

4.9.14 Who can request suspension

Suspension of certificates is not supported within PKIoverheid.

4.9.15 Procedure for suspension request

Suspension of certificates is not supported within PKIoverheid.

4.9.16 Limits on suspension period

Suspension of certificates is not supported within PKIoverheid.

4.10 Certificate Status Services

4.10.1 Operational characteristics

Revocation entries on a CRL or OCSP Response will not be removed until after the Expiry Date of the revoked Certificate.

Operational characteristics for CRL and any OCSP services for end-user certificates can be found in the CPS of the respective TSP.

4.10.2 Service availability

When offered, CRL and OCSP certificate status information services are available 24/7. CRL and OCSP are operated with sufficient resources to provide a response time of ten seconds or less under normal operating conditions.

4.10.3 Optional features

No stipulation.

4.11 End of subscription

No formal process exists for TSPs wanting to end issuing PKIoverheid certificates. Arrangements will be made between the PA PKIoverheid and the TSP wishing to end operations within PKIoverheid, to ensure continuity in PKIoverheid services towards existing end-entity certificate subscribers. Between PKIoverheid TSPs also exist business continuity agreements to ensure revocation and dissemination services continuity in case of disasters. These agreements also can be used for maintaining revocation and dissemination services for end-entity certificate subscribers whose TSP wishes to end issuing PKIoverheid certificates.

The process in case of ending the PKIoverheid ecosystem completely is described in Section 5.8.

4.12 Key escrow and recovery

4.12.1 Key escrow and recovery policy and practices

Key escrow is not in supported within the central hierarchy of PKIoverheid. Hence, no escrow policy and practices exist.

4.12.2 Session key encapsulation and recovery policy and practices

No stipulation.

5 Facility 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. 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 controls

The secured environment of the PKIoverheid root is set up based on the requirements formulated in the WebTrust Program for Certification Authorities and the Civil Service Information Security Classified Information Decree (Voorschrift Informatiebeveiliging Rijksinspectie voor Bijzondere Informatie in Dutch, or VIR-BI abbreviated).

5.1.1 Site location and construction

Both primary and disaster recovery locations used for key material storage, and both key and certificate generation ceremonies, are undisclosed high-security facilities.

5.1.2 Physical access

Both primary and disaster recovery locations have multiple physical security zones, each with additional access controls.

5.1.3 Power and air conditioning

No stipulation.

5.1.4 Water exposures

No stipulation.

5.1.5 Fire prevention and protection

No stipulation.

5.1.6 Media storage

Media containing private key material is stored off-line in vaults with multiple security barriers, both in the primary and disaster recovery location.

5.1.7 Waste disposal

Media with private key material, as well as hard disks used in certificate issuing machines, are destroyed by organizations certified to dispose of hardware containing classified information. All paperwork related to PKIoverheid processes is destroyed by a specialized and certified organization as well.

5.1.8 Off-site backup

After each root and intermediate certificate key pair generation, the private keys are cloned and transferred to a high-security disaster recovery location.

5.2 Procedural controls

Trusted roles are assigned either by the PKIoverheid PA or management of the PKIoverheid Key Management team. Each role has authorizations based on the principle of least privilege.

The list of personnel appointed to trusted roles is maintained and reviewed annually.

The functions and duties performed by persons in trusted roles are distributed so that a lone person cannot subvert the security and trustworthiness of PKI operations.

5.2.1 Trusted roles

PKIoverheid recognizes the following trusted roles:

1. Key Management administrators with the following responsibilities:
   1. Installing and configuring CA software;
   2. Key generation and key back-up;
   3. Certificate generation;
   4. Certificate issuance;
   5. Certificate revocation;
   6. Preparation of ceremonies;
   7. Maintaining Key Management Handbook;
2. Key Management operators with the following responsibilities:
   1. Install, configure, and maintain infrastructure for the PKI Dissemination Services;
   2. Install, configure, and maintain infrastructure for the PKI Revocation Services;
3. PA Officers with the following responsibilities:
   1. Review certificate issuance and revocation requests;
   2. Verification of identities related to certificate issuance and revocation requests;
   3. Can represent the PA for certain tasks;
   4. Maintaining CPS and PoR;
   5. Governance on compliance;
4. PA with the following responsibilities:
   1. Accountable for PA Officers;
   2. Accountable for issued root, intermediate and TSP issuing certificates
   3. Accountable for compliance with the different PKI standards and trust frameworks;
   4. Responsible for strategic goals and tactical decisions;
5. qualified auditors with the following responsibilities:
   1. Perform annual Webtrust audit;
   2. Witnessing certain key ceremonies;
6. Penetration testers with the following responsibilities:
   1. Perform penetration tests on Dissemination and Revocation service infrastructures.

5.2.2 Number of persons required per task

The following tasks need multiple persons different trust roles (not limited to the specific PKI trust roles in Section 5.2.1) to complete. The total number of persons and actual roles involved in these tasks will remain undisclosed in this CPS.

• Issue a signing/revocation certification request to PKIoverheid Key Management;
• Access to any and all physical vaults containing material related to the key ceremony process;
• Access to all but the first security zone in the primary and disaster recovery facility used for key/certificate ceremonies and private key storage;
• Operation of CA systems (exluding CA systems for Acceptance (ACC) and TRIAL environments);
• Operation of HSM’s for key generation and cloning (exluding key generation for Acceptance (ACC) and TRIAL environments).

In case of key/certificate generation ceremonies (exluding Acceptance (ACC) and TRIAL certificate ceremonies), there always is an independent external witness and a representative of the PA present. Any deviations from the ceremony script will be meticulously recorded. In addition to this, the entire ceremony is video recorded and saved. The recordings are stored and are available for playback for the Webtrust Auditor.

5.2.3 Identification and authentication for each role

Identification before key/certificate ceremonies is performed by verification of an identity document under article 1 of the Compulsory Identification Act (WID), limited to the following documents:

• a valid travel document referred to in the Passport Act (Paspoortwet (in Dutch));
• a valid driving licence issued on the basis of the Road Traffic Act (Wegenverkeerswet 1994 (in Dutch)) article 107.

Authentication on CA systems used in key/certificate ceremonies is done using multi-factor authentication.

5.2.4 Roles requiring separation of duties

Roles requiring separation of duties are task-specific. These are described in Section 5.2.2.

5.3 Personnel Security Controls

5.3.1 Qualifications, experience, and clearance requirements

The PKIoverheid PA verifies the identity and trustworthiness of all individuals assigned to trusted roles, as well as determines these persons perform their prospective job responsibilities competently and satisfactorily as required.

5.3.2 Background check procedures

Upon employment all Logius personnel have to show a Certificate of Conduct (Verklaring omtrent gedrag in Dutch, or VOG abbreviated). For specific trusted roles the PA can demand additional screening by either the General Intelligence Security Service (Algemene Inlichtingen- en Veiligheidsdienst in Dutch, or AIVD abbreviated) or the Dutch Military Intelligence and Security Service (Militaire Inlichtingen- en Veiligheidsdienst in Dutch, or MIVD abbreviated).

Additionally, the PA shall ensure that trusted personnel have no conflicting interests, in order to safeguard the impartiality of the activities of the PA.

5.3.3 Training requirements

No stipulation.

5.3.4 Retraining frequency and requirements

No stipulation.

5.3.5 Job rotation frequency and sequence

No stipulation.

5.3.6 Sanctions for unauthorized actions

No stipulation.

5.3.7 Independent contractor requirements

No stipulation.

5.3.8 Documentation supplied to personnel

No stipulation.

5.4 Audit logging procedures

5.4.1 Types of events recorded

The PKIoverheid PA records the following events:

1. Root and Intermediate certificate and key lifecycle events, including:
   1. Certificate requests, renewal, and re-key requests, and revocation;
   2. Approval and rejection of certificate requests;
   3. Cryptographic device lifecycle management events; and
   4. Introduction of new Certificate Profiles and retirement of existing Certificate Profiles.
2. TSP Issuing Certificate lifecycle management events, including:
   1. Certificate requests, renewal, and re-key requests, and revocation;
   2. Various verification activities stipulated in this Certification Practice Statement; and
   3. Approval and rejection of certificate requests.

Additionally, PKIoverheid Key Management records the following events:

1. Root and Intermediate certificate and key lifecycle events, including:
   1. Key generation, backup, storage, recovery, archival, and destruction;
   2. Generation of Certificate Revocation Lists;
   3. Signing of OCSP Responses.
2. TSP Issuing Certificate lifecycle management events, including:
   1. Issuance of Certificates;
   2. Generation of Certificate Revocation Lists; and
   3. Signing of OCSP Responses.
3. Security events, including:
   1. Successful and unsuccessful PKI system access attempts;
   2. PKI and security system actions performed;
   3. Security profile changes;
   4. Installation, update and removal of software on a Certificate System;
   5. System crashes, hardware failures, and other anomalies;
   6. Firewall and router activities; and
   7. Entries to and exits from the Key Management facility.

All log records include at least the following elements:

1. Date and time of event;
2. Identity of the person making the journal record; and
3. Description of the event.

5.4.2 Frequency of processing log

In general, logs are reviewed following an alarm or anomalous event, or when access is requested by auditors.

In the case of air-gapped CA systems, the log files of these systems are checked every key ceremony to confirm that no unauthorized changes have been made to these systems.

5.4.3 Retention period for audit log

Certificate and key lifecycle management event records related to PKIoverheid Root, Intermediate, and TSP Issuing Certificates as described in Section 5.4.1 are retained seven years after either the destruction of a corresponding Private Key, or the revocation or expiration of the certificate.

Security event records as set forth in Section 5.4.1 are retained a minimum of two years after the event occurred.

5.4.4 Protection of audit log

No stipulation.

5.4.5 Audit log backup procedures

No stipulation.

5.4.6 Audit collection system (internal vs. external)

No stipulation.

5.4.7 Notification to event-causing subject

No stipulation.

5.4.8 Vulnerability assessments

The PKIoverheid PA performs an annual Risk Assessment that:

1. identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;
2. assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and
3. assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the PA has in place to counter such threats.

5.5 Records archival

5.5.1 Types of records archived

Audit logs as set forth in Section 5.4.1 are retained as described in Section 5.4.3. This can be in either archived or non-archived form in any part of the retention period.

In addition to this, the following information is archived:

1. All documentation related to the security of Certificate Systems (related to Root, Intermediate, and TSP Issuing Certificates), Certificate Management Systems; and
2. All documentation relating to the verification, issuance, and revocation of certificate requests and Certificates after the later occurrence of:
   1. such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or
   2. the expiration of the Subscriber Certificates relying upon such records and documentation.

5.5.2 Retention period for archive

Audit logs as set forth in Section 5.4.1 are retained as described in Section 5.4.3. This can be in either archived or non-archived form in any part of the retention period.

The archival period of all other archived information is at least two years, or seven years after its creation date, whichever comes last.

5.5.3 Protection of archive

Access to archives is only available to personnel in trusted roles, based on Access Control Lists (ACLs). All information systems containing archived information have additional security measures in place as stipulated in the governemental baseline for information security (Baseline Informatiebeveiliging Overheid in Dutch, or BIO abbreviated).

5.5.4 Archive backup procedures

All information systems containing archives are backed-up automatically on a daily basis.

5.5.5 Requirements for time-stamping of records

No stipulation.

5.5.6 Archive collection system (internal or external)

No stipulation.

5.5.7 Procedures to obtain and verify archive information

No stipulation.

5.6 Key changeover

Private Keys corresponding to Public Keys in PKIoverheid Root, Intermediate, or TSP Issuing certificates normally are not 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. Only in rare circumstances key re-use will be allowed; see Section 4.7.

5.7 Compromise and disaster recovery

5.7.1 Incident and compromise handling procedures

An incident management process is in place based on the Information Technology Infrastructure Library (ITIL) framework.

Different incident types and severity levels are defined, each with its own handling procedures. Compromises are always of type “security incident” and can lead to certificate revocations. See Section 4.9.1 for more information about revocation reasons.

When necessary the PKIoverheid PA will also notify the applicable Application Software Suppliers and/or the Dutch Authority for Digital Infrastructure (Rijksinspectie voor Digitale Infrastructuur in Dutch, or RDI abbreviated, the eIDAS Supervisory Body for The Netherlands) on incidents.

5.7.2 Computing resources, software, and/or data are corrupted

PKIoverheid has a hot-stand-by environment in a secondary high-security site with back-ups of all data. In case of faulty equipment or data corruption which can not be corrected on-site, processes can be diverted to the secondary environment. These disaster recovery procedures are tested on a yearly basis.

5.7.3 Entity private key compromise procedures

See Section 4.9.1.

5.7.4 Business continuity capabilities after a disaster

See Section 5.7.2.

5.8 CA or RA termination

The process for TSPs wanting to terminate issuing PKIoverheid certificates is described in Section 4.11.

If the Ministry of the Interior and Kingdom Relations itself decides to end operation of PKIoverheid, it can choose to either terminate the PKIoverheid system completely, or transfer it to another organization. In case of complete PKIoverheid termination, the following actions will be executed:

1. All TSPs, end-entity certificate subcribers, and other relying parties within PKIoverheid, shall be informed at least six months before the service ends.
2. All certificates that are issued after announcement of termination of the service WILL NOT contain a NotAfter date which is later than 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 ceases to distribute certificates and CRLs.

If the Ministry of the Interior and Kingdom Relations decides to transfer the PKIoverheid service to a different organization, all TSPs, end-entity certificate subcribers, and other relying parties within PKIoverheid, 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.

6 Technical Security Controls

6.1 Key pair generation and installation

6.1.1 Key pair generation

The key pairs meant for 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 (Universal Serial Bus) stick or smartcard. Because key ceremonies for generation and the use of the signing key of the PA takes place occasionally, the computer systems are only used for this purpose. The critical components of the computer systems are always stored in a safe, except for during PKI ceremonies.

For all generated CA Key Pairs and all signed CAs that are to be operated by an external CA (TSP) the PA PKIoverheid will take the following actions:

1. prepare and follow a Key Generation Script;
2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process;
3. have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair;
4. generate the CA Key Pair in a physically secured environment as described in the CA’s CP and/or CPS;
5. generate the CA Key Pair using personnel in Trusted Roles under the principles of multiple person control and split knowledge;
6. generate the CA Key Pair within cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA’s CP and/or CPS;
7. log its CA Key Pair generation activities;
8. maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its CP and/or CPS and (if applicable) its Key Generation Script.

In cases where the CA key pair is not generated by the PA PKIoverheid (e.g. in case of signing TSP CAs), the applicable requirements listed above SHALL apply to that TSP instead.

6.1.2 Private key delivery to subscriber

PKIoverheid Key Management does not create key pairs for PKIoverheid TSPs. Hence, no private keys need to be delivered to subscribers.

6.1.3 Public key delivery to certificate issuer

Public keys from PKIoverheid TSPs are delivered to PKIoverheid Key Management using secure email and/or secure cloud transfer services.

6.1.4 CA public key delivery to relying parties

No stipulation.

6.1.5 Key sizes

All PKIoverheid Root certificates, Intermediate certificates, TSP Issuing certificates, and OCSP Signing certificates are of type RSA (the Ron Rivest, Adi Shamir and Len Adleman asymmetric encryption algorithm) and have a key length of 4096 bytes.

6.1.6 Public key parameters generation and quality checking

No stipulation.

6.1.7 Key usage purposes (as per X.509 v3 key usage field)

See keyUsage field descriptions in Section 7.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic module standards and controls

Private keys related to PKIoverheid Root and Intermediate certificates always reside on a Hardware Security Module (HSM) that meets either the requirements identified in Federal Information Processing Standard (FIPS) publication 140-2 Level 3, or ISO 15408 at Evaluation Assurance Level (EAL) 4+ or equivalent security criteria.

6.2.2 Private key (n out of m) multi-person control

All operations with private keys related to PKIoverheid Root and Intermediate certificates need multiple authorized people from different teams to be present and unlock the needed functionalty.

6.2.3 Private key escrow

Escrow of private keys related to PKIoverheid Root and Intermediate certificates is not allowed.

6.2.4 Private key backup

Cloned private keys related to all the PKIoverheid Root and Intermediate certificates, but excluding TRIAL certificates, are stored in the PKIoverheid Disaster Recovery location with the same (technical) security controls as the operational private keys. The private keys related to the PKIoverheid TRIAL Root and Intermediate certificates have no backup.

6.2.5 Private key archival

When a PKIoverheid Root or Intermediate certificate expires or is revoked, its private key will not be archived but destroyed in a timely fashion. See Section 6.2.10 for more information on private key destruction.

6.2.6 Private key transfer into or from a cryptographic module

Cloning of private keys between the primary HSM and Disaster Recovery HSM is the only transfer operation of PKIoverheid private keys allowed.

6.2.7 Private key storage on cryptographic module

The private keys related to all PKIoverheid Root and Intermediate certificates are stored on an HSM. See section 6.2.1.

6.2.8 Method of activating private key

Private keys related to PKIoverheid Root and Intermediate certificates are off-line. Activation of these keys therefore only happens during key ceremonies.

Only the private keys related to PKIoverheid TRIAL Root and Intermediate certificates can be activated directly by members of the PKIoverheid Key Management team, the procedure of which is described in the Key Management Handbook. This handbook is updated at least annualy.

6.2.9 Method of deactivating private key

No stipulation.

6.2.10 Method of destroying private key

Destroying a Private Key comprises of removing it from both active and back-up HSMs.

6.2.11 Cryptographic Module Rating

See Section 6.2.1.

6.3 Other aspects of key pair management

6.3.1 Public key archival

Public keys related to PKIoverheid Root, Intermediate, and TSP Issuing certificates are only archived as part of the certificates themselves.

6.3.2 Certificate operational periods and key pair usage periods

For PKIoverheid certificates the following maximum operational periods (certificate validity field) apply:

• Root certificates: 15 years;
• Intermediate certificates: 15 years minus 1 day;
• TSP Issuing certificates: 15 years minus 2 days;
• OCSP Responder certificates: 365 days.

6.4 Activation data

Activation data refers to data values other than whole Private Keys that are required to operate Private Keys or cryptographic modules containing Private Keys. Examples of activation data include, but are not limited to, Personal Identification Numbers (PINs), passphrases, and portions of Private Keys used in a key-splitting regime.

6.4.1 Activation data generation and installation

Activation data is generated in accordance with the specifications of the HSM.

6.4.2 Activation data protection

Activation data is stored in separate seal bags in separate compartments in different PKIoverheid secured safes of which the keys are held by different shareholders.

6.4.3 Other aspects of activation data

No stipulation.

6.5 Computer security controls

6.5.1 Specific computer security technical requirements

PKIoverheid Key Management has implemented all technical computer security requirements as described in the Network and Certificate System Security Requirements CA/Browser Forum document, as well as relevant technical ISO 27001 requirements.

6.5.2 Computer security rating

The hardware and software used in the central hierarchy for the key management is classified by the Dutch National Communications Security Agency (Nationaal Bureau voor Verbindingsbeveiliging in Dutch, or NBV abbreviated) at level “Staatsgeheim CONFIDENTIEEL”. This Dutch classification level is comparable to the governmental classification “Confidential” used in both the United Kingdom and the United States, as well as in the North Atlantic Treaty Organization (NATO).

6.6 Life cycle technical controls

6.6.1 System development controls

Changes to information systems are implemented using a formal change management process, including a separate environment for acceptance testing. Before entering the formal change management process, initial development and testing is done on another environment for development purposes.

6.6.2 Security management controls

The PKIoverheid team has implemented all security management controls described in Baseline Informatiebeveiliging Overheid (BIO) which isbased on ISO 27001. For publicly-trusted certificates this also includes the security management controls described in the CA/Browser Forum “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates”.

6.6.3 Life cycle security controls

The PKIoverheid team has implemented all security life-cycle controls described in the Baseline Informatiebeveiliging Overheid (BIO) which is based on ISO 27001. For publicly-trusted certificates this also includes the security life-cycle controls described in the CA/Browser Forum “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates”.

6.7 Network security controls

The PKIoverheid team has implemented all security network controls described in Baseline Informatiebeveiliging Overheid (BIO) which isbased on ISO 27001, as well as the CA/Browser Forum “Network and Certificate System Security Requirements” for its network-connected systems.

6.8 Time-stamping

PKIoverheid does not support a time-stamping service as part of its services portfolio.

For time-stamping of its own OCSP responses a trustworthy Network Time Protocol (NTP) server is used. Dates in PKIoverheid Root, Intermediate, and TSP Issuing certificates, are entered manually and based on the time displayed on ceremony member’s mobile devices which are synchronized with the network time of their mobile telephony providers.

7 Certificate and CRL, and OCSP profiles

7.1 Certificate profile

The table below contains all fields to be used in PKIoverheid certificates. PKIoverheid certificates do not contain any fields and extensions other than those described in the table. Contents and usage of certificate fields can differ per PKIoverheid certificate type (for an overview, see Section 1.1 of this CPS). For each separate certificate field the table shows which usages and contents are applicable for which certificate type. All fields comply with IETF CRL Profile RFC 5280.

Note: All actual field values can be found on https://cert.pkioverheid.nl.

7.1.1 Version number(s)

See Section 7.1.

7.1.2 Certificate extensions

See Section 7.1.

7.1.3 Algorithm object identifiers

See Section 7.1.

7.1.4 Name forms

See Section 7.1.

7.1.5 Name constraints

See Section 7.1.

7.1.6 Certificate policy object identifier

See Section 7.1.

A complete list of all PKIoverheid OIDs can be found in the PKIoverheid OID Registration document. See Section 2.1 for the location of this document.

7.1.7 Usage of Policy Constraints extension

The policyConstraints extension is not used within PKIoverheid.

7.1.8 Policy qualifiers syntax and semantics

See Section 7.1.

7.1.9 Processing semantics for the critical Certificate Policies extension

No stipulation.

7.2 CRL profile

The table below contains all fields to be used in PKIoverheid Certificate Revocation Lists (CRLs). PKIoverheid CRLs do not contain any fields and extensions other than those described in the table. Contents and usage of certificate fields can differ per PKIoverheid certificate type (for an overview, see Section 1.1 of this CPS). For each separate CRL field the table shows which usages and contents are applicable for which certificate type. All fields comply with the CRL profile described in RFC 5280.

7.2.1 Version number(s)

See Section 7.2.

7.2.2 CRL and CRL entry extensions

See Section 7.2.

7.3 OCSP profile

The table below contains all fields to be used in OCSP Responses for both PKIoverheid Intermediate and PKIoverheid TSP Issuing certificate status requests. All fields comply with IETF RFC 6960.

7.3.1 Version number(s)

See Section 7.3.

7.3.2 OCSP extensions

If applicable, see Section 7.3.

8 Compliance Audit and Other Assessment

8.1 Frequency or circumstances of assessment

The PA of PKIoverheid complies with the requirements described in the latest version of the WebTrust Principles and Criteria for Certification Authorities. Each year, the PA of PKIoverheid undergoes an full period-of-time audit for this.

The PA PKIoverheid actively monitors the changes in the WebTrust Principles that affect this CPS. The PA PKIoverheid also actively monitors changes in the S/MIME 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 are assessed and, if deemed necessary, incorporated in the PoR and/or this CPS.

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

8.2 Identity/qualifications of assessor

Audits are performed by an external certified WebTrust for CAs auditor. These auditors meet the requirements of Section 8.2 of the CA/Browser Forum Baseline Requirements and are experienced in performing information security audits, and have significant experience with PKI and cryptographic technologies.

8.3 Assessor’s relationship to assessed entity

The assessor performing the audit of PKIoverheid is an independent third party.

8.4 Topics covered by assessment

The following assessment frameworks are used to audit PKIoverheid certificates capable of issuing other certificates:

1. WebTrust Principles and Criteria for Certification Authorities Framework (WTCA)
2. WebTrust Principles and Criteria for Certification Authorities - S/MIME Framework (WTSM)
3. WebTrust Principles and Criteria for Certification Authorities - SSL Baseline with Network Security Framework (WTBR)

The table below shows which assessment framework is used to audit which type of PKIoverheid certificate capable of issuance.

The latest version of this assessment framework is being used. Topics covered in this assessment framework can be found on the website of Chartered Professional Accountants (CPA) Canada (https://www.cpacanada.ca).

8.5 Actions taken as a result of deficiency

When an Auditor reports a deficiency, the PKIoverheid PA will develop a Corrective Action Plan (CAP) to correct the deficiency, which could involve changing its policies or practices, or both. The amended policies and/or practices will be put into operation and the Auditor will be required to verify that the deficiency is no longer present.

8.6 Communicating of results

Through a WebTrust seal, published yearly on the Logius website, the PA PKIoverheid demonstrates that it meets the WebTrust requirements. The PA publishes this seal and accompanying Management Assertion no longer than 3 months after expiry of the previous audit period.

Audit Statements of all Root, Intermediate and TSP Issuing certificates in scope of WebTrust are submitted to the Common Certificate Authority Database (CCADB).

8.7 Self-audits

No stipulation.

9 Other Business and Legal Matters

9.1 Fees

9.1.1 Certificate issuance or renewal fees

No stipulation.

9.1.2 Certificate access fees

All PKIoverheid Root, Root, and OCSP SIgning certificates 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 or OCSP),
• consulting the Programme of Requirements: Certificate Policies, and
• consulting this CPS.

9.1.3 Revocation or status information access fees

No stipulation.

9.1.4 Fees for other services

No stipulation.

9.1.5 Refund policy

No stipulation.

9.2 Financial responsibility

9.2.1 Insurance coverage

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

9.2.2 Other assets

No stipulation.

9.2.3 Insurance or warranty coverage for end-entities

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.

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

9.3 Confidentiality of business information

9.3.1 Scope of confidential information

No stipulation.

9.3.2 Information not within the scope of confidential information

No stipulation.

9.3.3 Responsibility to protect confidential information

The PA 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 Privacy of personal information

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

9.4.1 Privacy plan

Not applicable.

9.4.2 Information treated as private

Not applicable.

9.4.3 Information not deemed private

Not applicable.

9.4.4 Responsibility to protect private information

Not applicable.

9.4.5 Notice and consent to use private information

Not applicable.

9.4.6 Disclosure pursuant to judicial or administrative process

Not applicable.

9.4.7 Other information disclosure circumstances

Not applicable.

9.5 Intellectual property rights

This document is made available to the general public under the CC-BY-ND 4.0 license.

9.6 Representations and warranties

9.6.1 CA representations and warranties

PKIoverheid conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates and the Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates where applicable. Both Baseline Requirements are published at https://cabforum.org. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.

9.6.2 RA representations and warranties

No stipulation.

9.6.3 Subscriber representations and warranties

No stipulation.

9.6.4 Relying party representations and warranties

No stipulation.

9.6.5 Representations and warranties of other participants

No stipulation.

9.7 Disclaimers of warranties

See Section 9.2.

9.8 Limitations of Liability

See Section 9.2.

9.9 Indemnities

See Section 9.2.

9.10 Term and termination

9.10.1 Term

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 PKIoverheid continue or until the CPS is replaced by a newer version. The latest version can always be found in the electronic repository mentioned in Section 2.1.

9.10.2 Termination

No stipulation.

9.10.3 Effect of termination and survival

No stipulation.

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.

Besides communications with the TSPs, frequent contact also takes place with the Dutch Authority for Digital Infrastructure (Rijksinspectie voor Digitale Infrastructuur in Dutch, or RDI abbreviated) and the auditor(s) of the participating TSPs. See document *Samenwerkingsprotocol Logius en de Rijksinspectie Digitale Infrastructuur (in Dutch) for additional information.

9.12 Amendments

9.12.1 Procedure for amendment

Within PKIoverheid there exist three different policy documents:

1. this CPS,
2. the Program of Requirements for PKIoverheid TSPs, and
3. the Registration of PKIoverheid OIDs.

Procedures for amendments differ between these three documents.

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

Program of Requirements for PKIoverheid TSPs

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 a observer. 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 these bodies is to 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 organised 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. Currently, this is the director of the directorate for Information Society and Government from the Ministry of the Interior and Kingdom Relations.
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 honoured 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:
   1. the Ministry of the Interior and Kingdom Relations;
   2. the PA PKIoverheid (PA);
   3. 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 by the Change Council and Framework Council. If a change cannot wait until the next version of the PoR, an abbreviated change procedure is available.
4. A change proposal can be submitted by creating an issue in the private GitHub repository that the PA uses for managing documents. If so desired, a proposal can also be accompanied by a text proposal. In that case a Pull Request can be openened.
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 an actual (material) change the PA will analyse the proposal and has the ability to outright reject said proposal. If the PA agrees with the (goal of the) change propopsal it will issue a positive recommendation, including text proposal, impact analysis (for instance: effective dates and possible dispensation) and reasoning. These are submitted to the TSPs for consultation.

Regular 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. Change proposals are sent to the TSPs at least ten weeks before the publication of the new PoR version is due.
3. 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.
4. TSPs have five weeks to analyse change proposals and to give feedback to the PA.
5. This feedback is discussed during the Change Council meeting prior to the meeting of the Framework Council.
6. Taking the Change Council input into consideration, change proposals are finalised.
7. 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 2 weeks between the Change Council meeting and the Framework Council meeting.
8. The final change proposals are sent to the TSPs and the auditors no later than 2 working days after the Change Council meeting, along with the agenda for the Framework Council meeting.
9. The response time of TSPs to the agenda and the final change proposals is at least one week.
10. 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.
11. 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 in writing concerning the content and the effective date of changes.
12. Following the Framework Council meeting, the PoR will be published as soon as possible.
13. The effective dates of changes are specifically included in the PoR.

Ordinary change process in weeks

The regular change process has the following chronological steps and lead times in weeks. Starting point is the final date for submission of concepts:

1. +5 weeks for TSPs for submitting feedback;
2. +1 week before earliest date of the Change Council Meeting;
3. +2 weeks to submit final change proposals;
4. • any number of weeks for TSPs to submit final feedback and agenda items;
5. +1 week before earliest date of the Framework Council Meeting;
6. • any number of weeks for publishing the new PoR;
7. +4 weeks before earliest effective date for new changes.

This is visualized in Figure 3 below.

Figure 3 Image with overview of ordinary change process in weeks

Accelerated change procedure

1. Changes are usually dealt with through the regular change procedure. In the event of an (imminent) incident, change in external requirements (For instance, a change in browser policy), 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:
   1. 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.
   2. TSPs have at least one week to submit objections to the content and/or effective date of this change.
   3. Any objections will be carefully considered by the PA PKIoverheid which, in close consultation, shall endeavour to provide sound advice.
   4. The decision making process followed by the Ministry of the Interior and Kingdom Relations is described in the paragraph entitled “Decision-making”.
   5. 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.

Registration of PKIoverheid OIDs

The PKIoverheid PA is itself fully responsible for maintaining and decision making regarding the PKIoverheid OID naming arc.

9.12.2 Notification mechanism and period

Any changes to PKIoverheid policy documents are announced through the agreed channels with all PKIoverheid TSPs.

9.12.3 Circumstances under which OID must be changed

No stipulation.

9.13 Dispute resolution provisions

Dispute resolution provisions are described in various individual agreements between Logius PKIoverheid and its TSPs.

9.14 Governing law

Dutch law applies.

9.15 Compliance with Applicable Law

The PA function is performed by Logius. Logius is a digital government service and is part of BZK. The General Administrative Law Act (Algemene wet bestuursrecht in Dutch) applies to Logius.

9.16 Miscellaneous provisions

9.16.1 Entire agreement

No stipulation.

9.16.2 Assignment

No stipulation.

9.16.3 Severability

No stipulation.

9.16.4 Enforcement (attorneys’ fees and waiver of rights)

No stipulation.

9.16.5 Force Majeure

No stipulation.

9.17 Other provisions

No stipulation.