Table of Contents

1 Introduction

The Certification Practice Statement within the PKI for the government (hereinafter referred to as CPS) provides TSPs, subscribers and relying parties with information regarding the procedures and measures taken in respect of the PA’s services with regard to certificates issued by the following “Staat der Nederlanden” root certificates:

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

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 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 PKIoverheid 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 Certification Practice Statements of the PKIoverheid Trust Service Providers. These CPS’s comply with the PKIoverheid Certificate Policy, called the PKIoverheid Program of Requirements (PoR). The PKIoverheid PoR describes the minimum requirements in relation to the different trust services a TSP can provide within PKIoverheid.

The image below shows the three PKIo root certificates for production environments and their respective hierarchies.

Figure 1 Image containing overview hierarchies of all PKIoverheid roots (excluding TRIAL)

The hierarchy for PKIoverheid TRIAL certificates can be found in the following image.

Figure 2 Image containing overview hierarchy of TRIAL PKIoverheid root

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

This section shows the revisions of both the current unified CPS, and the revisions of the separate CPSs before the decision was made to unify them in one document. Thus, this section contains the following revision tables:

• Revisions for the PKIo unified CPS (CURRENT)
• Revisions for the PKIo G2 and G3 CPS (DEPRECATED)
• Revisions for the PKIo EV CPS (DEPRECATED)
• Revisions for the PKIo Private CPS (DEPRECATED)
• Revisions for the PKIo TRIAL CPS (DEPRECATED)

Revisions for the PKIo unified CPS (CURRENT)

Revisions for the PKIo G2, and G3 CPS (DEPRECATED)

Revisions for the PKIo EV CPS (DEPRECATED)

Revisions for the PKIo Private CPS (DEPRECATED)

Revisions for the PKIo TRIAL CPS (DEPRECATED)

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 (BZK) is responsible for PKIoverheid. The Ministry of the Interior and Kingdom Relations 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.

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

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

1.3.1 Certification authorities

The PKIo Policy Authority, as well as TSPs issuing end user certificates, can be regarded a certification Authorities. Both are described separately in underlying sections.

1.3.1.1 PKIo Policy Authority

The Policy Authority (PA) of the PKI for the Dutch government (PA PKIoverheid) 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 the PKI for the government, the Programme of Requirements (PoR),
2. the PKIoverheid Certificate Policy (CP); assisting Trust Service Providers (TSPs) in the process of admittance to PKI for the government and preparing the administrative handling,
3. supervising and monitoring the activities of TSPs issuing certificates for the government under the root of the PKI for the government.

The Policy Authority (PA) is responsible for managing the top tiers (level 1 and 2) of the hierarchy. PKIoverheid is structured so that external organizations, the Trust Service Providers (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 CRL; 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 (OCPS) responders.

The PKIoverheid Policy Authority is part of Logius (http://www.logius.nl), the digital government service of the Ministry of the Interior and Kingdom Relations.

1.3.1.2 Trust Service Providers

An up-to-date list of all PKIo Trust Service Providers, and the type(s) of certificates they are capable of issuing, can be found on: https://cert.pkioverheid.nl

1.3.2 Registration authorities

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 (Dutch: Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, or BZK): 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. Radiocommunications Agency Netherlands (Dutch: Agentschap Telecom, or AT): The Radiocommunications Agency Netherlands is the Dutch National Accreditation body for eIDAS Qualified TSP’s, as wel as a regulatory body for the supervision of TSPs operating in the Netherlands.
3. National Cyber Security Centre (Dutch: Nationaal Cyber Security Centrum, or NCSC): The NCSC advises on certificate usage within the Dutch government.

1.4 Certificate Usage

See sub-sections.

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 differrent purposes:

• Domain Server 2020:
  • server authentication;
• 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.

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 TSP CA (level 3), Domain CA (level 2), Root CA (level 1) and/or their associated OCSP responders and/or CRLs the reporting party should contact Logius through the contact information below. Revocation procedures are also described in section 4.9.1. and 4.9.3. of this CPS.

Policy Authority PKIoverheid
Wilhelmina van Pruisenweg 52
P.O. Box 96810
2509 JE THE HAGUE
NETHERLANDS

Website: <https://www.logius.nl/pkioverheid>

General telephone number: +31(0)708896360

Email: <servicecentrum@logius.nl>

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 Baseline Requirements document applies. The PA determines if changes in the PKIoverheid policies are needed after updates to the CA/B Forum 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

See sub-sections.

1.6.1 Definitions

Definitions used in this CPS and the Programme of Requirements are listed in part 4 of the 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 part 4 of the PoR, which can be found at https://www.logius.nl/english/pkioverheid.

2 Publication and electronic repository responsibilities

See sub-sections.

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 and OID Registration are published on the PKIoverheid product page on the Logius website: https://www.logius.nl/english/pkioverheid
• 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 on both 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.

Test websites for Application Software Suppliers (per BRG 2.2) are available on the following URLs:

• https://roottest-ev.pkioverheid.nl
• https://roottest-ev-expired.pkioverheid.nl
• https://roottest-ev-revoked.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 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

See sub-sections.

3.1 Naming

See sub-sections.

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 ITU-T X.520 attribute naming scheme.

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 country code associated with the country of incorporation of the issuer- or subject-organization, as can be found in a Chamber of Commerce’s Trade Register 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 organisation name of the subject, a meaningful certificate identifier, and a generation identifier. - organizationIdentifier: Contains the respective organization’s Chamber of Commerce number.

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 rare circumstances the subject:commonName field does not always uniquely identify the certificate itself.

3.1.6 Recognition, authentication and role of trademarks

All organisationName 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

See sub-sections.

3.2.1 Initial Registration Process

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

3.2.2 Authentication of organizational identity

Based on the application form and the evidence that is supplied, the PA verifies, - That the TSP is an existing organization listed in the National Trade Register (NHR) or an organizational entity that forms part of an existing organization listed in the NHR. If a government organization is not listed in the NHR, the 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.). The excerpt must be original and must not be older than 13 months.

Note: If the participating party has existed for less than three years and does not appear in the latest version of the 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);
• a valid driving license issued on the basis of the Road Traffic Act (Wegenverkeerswet), under article 107 of the Road Traffic Act (Wegenverkeerswet) 1994.

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

See sub-sections.

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

See sub-sections.

4.1 Certificate Application

See sub-sections.

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 CSR had to be provided with the template.

Certificate proposals for new root or intermediate certificates can be submitted by the PKIoverheid PA itself, at the instruction of the Ministry of the Interior and Kingdom Relations.

4.2 Certificate application processing

See sub-sections.

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 application which pass the identification and authentication checks first a naming document is created for a trial 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

No stipulation.

4.3 Certificate issuance

See sub-sections.

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. All creation ceremonies takes place in the presence of independent witnesses, including an internal or external 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. building the computer system for certificate issuance;
2. installing and configuring the PKI software;
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.

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

See sub-sections.

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

See sub-sections.

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

See sub-sections.

4.6.1 Circumstance for certificate renewal

Normal certificate renewal happens when a certificate’s validity period is close to expiring. Only when information which is included in a certificate, changes or is out of date, this is reason for an early renewal. 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.

The PKIoverheid PA aims to introduce a new generation of each PKIoverheid root certificate once every five years. The previous generation will exist alongside the new one until it expires. This method ensures enough time for TSPs and en-users to transition to the new generation.

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

It is PKIoverheid policy to not support changing the existing public key in a certificate (also known as certificate re-key). Only in rare cases deviation from this policy will be considered by the PKIoverheid PA when substantial reasons exist to do so.

4.7.1 Circumstance for certificate re-key

Not applicable.

4.7.2 Who may request certification of a new public key

Not applicable.

4.7.3 Processing certificate re-keying requests

Not applicable.

4.7.4 Notification of new certificate issuance to subscriber

Not applicable.

4.7.5 Conduct constituting acceptance of a re-keyed certificate

Not applicable.

4.7.6 Publication of the re-keyed certificate by the CA

Not applicable.

4.7.7 Notification of certificate issuance by the CA to other entities

Not applicable.

4.8 Certificate modification

Certificate Modification is not supported within the central hierarchy of PKIoverheid. When modifications need to take place, this has to be done through the certificate renewal process (see Section 4.6).

4.8.1 Circumstance for certificate modification

Not applicable.

4.8.2 Who may request certificate modification

Not applicable.

4.8.3 Processing certificate modification requests

Not applicable.

4.8.4 Notification of new certificate issuance to subscriber

Not applicable.

4.8.5 Conduct constituting acceptance of modified certificate

Not applicable.

4.8.6 Publication of the modified certificate by the CA

Not applicable.

4.8.7 Notification of certificate issuance by the CA to other entities

Not applicable.

4.9 Certificate revocation and suspension

See sub-sections.

4.9.1 Circumstances for revocation

Revocation of Intermediate, TSP Issuing, or OCSP-Signing certificates will in any case be considered if the private key belonging to the certificate is compromised or suspected to be compromised. Indicators of private key compromise may include: - Theft or loss of device holding a private key; - Audit findings indicating private key compromise; - CT Log findings indicating unauthorized certificate signing; - Incidents reported to Logius by third parties which may indicate key compromise.

All indicators are registered, analyzed, and followed up accordingly.

The PA considers compromise of an intermediate or a TSP issuing certificate’s private key to be an emergency, and will be dealt with accordingly, as described in Section 5.7 of this CPS.

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.

The following list of circumstances are all reasons for revocation. The list also shows the associated cRLReason codes which have to be used in CRL’s or OCSP responses. - 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

These reasons for revocation are described in more detail below.

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.

Additionally, TSP signed signatories can request revocation of their issuing certificates. They have to send this request to the PKIoverheid PA who passes it on to PKIoverheid Key Management.

Root certificates cannot be revoked, and have to be removed from trusted root stores instead. The Ministry of the Interior and Kingdom Relations has to approve the removal of PKIoverheid root certificates from trust stores.

4.9.3 Procedure for revocation request

Prior to distrust of a root certificate, or revocation of an intermediate or TSP issuing certificate, a careful assessment process is followed. The emergency team will perform this assessment and will initiate any activities that may ensue from this.

Prior to distrusts of revocations, all PKIoverheid TSPs will be informed.

4.9.4 Revocation request grace period

No stipulation.

4.9.5 Time within which CA must process the revocation request

PKIoverheid Key Management will process a revocation within one working day after reception of a request.

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

CRLs for ALL PKIoverheid intermediate and TSP issuing certificates can be found at: http://crl.pkioverheid.nl.

OCSP for PKIoverheid intermediate and TSP issuing certificates can be found at:

• for “Staat der Nederlanden Domein Server CA 2020 CA” intermediate certificate: http://evrootocsp.pkioverheid.nl;
• for all underlying TSP issuing certificates: http://domserver2020ocsp.pkioverheid.nl;
• for “Staat der Nederlanden Organisatie Services CA - G3” intermediate certificate: http://rootocsp-g3.pkioverheid.nl;
• for all underlying TSP issuing certificates: http://domorganisatieservicesocsp-g3.pkioverheid.nl .

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

See sub-sections.

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

The OCSP service has the same availability as the CRL service. CRL service availability is described in Section 4.9.9.

4.10.3 Optional features

There are no further provisions for certificate status services on PKIoverheid Intermediate certificates, TSP Issuing certificates, or OCSP-Signing certificates.

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

See sub-sections.

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 root of the PKI for the government is set up based on the requirements formulated in the WebTrust Program for Certification Authorities, the Civil Service Information Security Classified Information Decree (Voorschrift Informatiebeveiliging Rijksdienst voor Bijzondere Informatie (VIR-BI)).

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

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;

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;

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;

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;

External auditors with the following responsibilities: 1. Perform annual Webtrust audit; 2. Witnessing certain key ceremonies;

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 used during key/certificate ceremonies (exluding ACC and TRIAL certificate ceremonies);
• Operation of HSM’s for key generation and cloning (exluding ACC and TRIAL key generation).

In case of key/certificate generation ceremonies (exluding 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 during 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); - a valid driving licence issued on the basis of the Road Traffic Act (Wegenverkeerswet 1994) 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

See sub-sections.

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 (Dutch: Verklaring omtrent gedrag). For specific trusted roles the PA can demand additional screening by either the General Intelligence Security Service (AIVD) or the Dutch Military Intelligence and Security Service (MIVD).

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

See sub-sections.

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

See sub-sections.

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

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

See sub-sections.

5.7.1 Incident and compromise handling procedures

An incident management process is in place based on the 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 Agentschap Telecom 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-sitet, 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 end 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 end PKIoverheid completely, or transfer it to another organization. In case of ending PKIoverheid completely, the following actions will be undertaken:

1. All TSPs, end-entity certificate subcribers, and other relying parties within PKIoverheid, shall be informed 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

See sub-sections.

6.1 Key pair generation and installation

See sub-sections.

6.1.1 Key pair generation

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

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.

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

See sub-sections.

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 FIPS PUB 140-2 Level 3, or ISO 15408 at evaluation guarantee 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.

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.

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

See sub-sections.

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

6.4.3 Other aspects of activation data

No stipulation.

6.5 Computer security controls

See sub-sections.

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 Nationaal Bureau voor Verbindingsbeveiliging (NBV) at level “Staatsgeheim confidentieel”. This level is Comparable to “Confidential” in UK/US government classifications.

6.6 Life cycle technical controls

See sub-sections.

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

See sub-sections.

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 Policy Constraints 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 IETF CRL Profile" >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

See sub-sections.

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 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 – SSL Baseline with Network Security” Framework (WTSSL)
3. “WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL” Framework (WTEV)

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

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

^[1] Currently the only remaining EV Intermediate certificate is “CA Server 2020” which does not actually issue EV certificates. Therefore WTEV is not applicable although it technically is in the EV hierarchy.

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

The PKIoverheid PA self-audits all certificates submitted to a CT-Log through automated linting software.

Additionally, the PKIoverheid PA performs a yearly self-assessment based on the Mozilla “Template for Compliance Self-Assessment” (see: https://docs.google.com/spreadsheets/d/1ExZE6PWIBM8rV9c6p6fFxOWmZyvf6X4ucMQRv7usHEk/edit?usp=sharing).

9 Other Business and Legal Matters

See sub-sections.

9.1 Fees

See sub-sections.

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

See sub-sections.

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

See sub-sections.

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

See sub-sections.

9.6.1 CA representations and warranties

TSP Issuing certificates issued by the PKIoverheid PA cannot be used to create additional sub-CAs. For a description of aditional safeguards, please refer to the relevant Certification Practice Statements of the PKIoverheid Trust Service Providers.

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

See sub-sections.

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 AT Radiocommunications Agency (see also: https://www.agentschaptelecom.nl/onderwerpen/zakelijk-gebruik/eidas-elektronische-vertrouwensdiensten/trust-service-providers) and the auditor(s) of the participating TSPs.

9.12 Amendments

See sub-sections.

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 completing the request form “Change proposal Programme of Requirements” and sending this to the PA. This form can be found on the PA’s website or can be requested directly from the PA.
5. The PA handles a submitted change proposal regarding a part of, or a provision in the PoR in accordance with documented internal processes. In the event of 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.

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.

Miscellaneous

1. The PoR and the approved changes can be obtained in electronic form via the Internet on the PA’s website: http://www.logius.nl/pkioverheid.
2. In the PoR, reference is made to this change procedure, which is included in the CPS of PKIoverheid.

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 the Ministry of the Interior and Kingdom Relations Government organizations. The General Administrative Law Act (in Dutch) applies to Logius (see: https://wetten.overheid.nl/BWBR0005537/2018-09-19).

9.16 Miscellaneous provisions

See sub-sections.

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.