Certification Practice Statement Policy Authority PKIoverheid Unified v5.4

Table of Contents

1 Introduction

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

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

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

1.1 Overview

This CPS describes the practices for the core PKI services of Staat der Nederlanden Root Certificates (Level 1) and Intermediate Certificates (Level 2). Core PKI services include:

• Registration Service: operated by both TSPs and described in their own CPS documentation in accordance with the Programme of Requirements.
• Generation Service: operated by both TSPs and PKIoverheid
• Dissemination Service: operated by both TSPs and PKIoverheid
• Subject Device Provisioning Service: operated by both TSPs and PKIoverheid
• Revocation Management Service: operated by both TSPs and PKIoverheid
• Revocation Status Service: operated by both TSPs and PKIoverheid

TSPs operate their own core PKI services for the management of their own PKIoverheid issuing certificates and issuance of PKIoverheid certificates to subscribers, all within the boundaries of applicable requirements set out by the PA PKIoverheid, found in the PKIoverheid Programme of Requirements (PoR). The PKIoverheid PoR can be regarded as a CP for PKIoverheid TSPs. General PKIoverheid practices can be found in this PoR but for practices specific to each TSP their respective CPS documents should be consulted.

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

• Root certificate Staat der Nederlanden Root CA - G3 (Publicly Trusted, in Mozilla and Microsoft Root Stores)
  • Intermediate certificate Staat der Nederlanden Burger CA - G3 (Legacy, S/MIME-capable)
    • TSP certificate TSP Burger CA - G3 (Legacy, EU Trust List)
  • Intermediate Staat der Nederlanden Autonome Apparaten CA - G3 (Legacy, S/MIME-capable)
    • TSP certificate TSP Autonome Apparaten CA - G3
  • Intermediate Staat der Nederlanden Organisatie Services CA - G3 (Legacy, S/MIME-capable)
    • TSP certificate TSP Organisatie Services CA - G3 (Legacy, EU Trust List)
  • Intermediate Staat der Nederlanden Organisatie Persoon CA - G3 (Legacy, S/MIME-capable)
    • TSP certificate TSP Organisatie Persoon CA - G3 (Legacy, EU Trust List)
  • Intermediate certificate Staat der Nederlanden Citizen CA - 2023 (non-S/MIME)
    • TSP certificate TSP Citizen CA - 2023 (EU Trust List)
  • Intermediate Staat der Nederlanden Organization Services CA - 2023 (non-S/MIME)
    • TSP certificate TSP Organization Services CA - 2023 (EU Trust List)
  • Intermediate Staat der Nederlanden Organization Person CA - 2023 (non-S/MIME)
    • TSP certificate TSP Organization Person CA - 2023 (EU Trust List)
  • Intermediate Staat der Nederlanden S/MIME CA - G3 2023 (S/MIME-capable; strict profile only)
    • TSP certificate TSP S/MIME CA - G3 2023 (Sponsor-validated, Organization-validated, and Individual-validated)
• Root Staat der Nederlanden Private Root CA - G1 (Not publicly trusted)
  • Intermediate Staat der Nederlanden Private Services CA - G1 (S/MIME-capable)
    • TSP certificate TSP Private Server CA - G1
    • TSP certificate TSP Private Organisatie Services CA - G1 (S/MIME-capable)
  • Intermediate Staat der Nederlanden Private Personen CA - G1 (S/MIME-capable)
    • TSP certificate TSP Private Personen CA - G1 (EU Trust List)
• Root Staat der Nederlanden - G4 Root Publ G-SMIME - 2024 (To be publicly trusted)
  • Intermediate Staat der Nederlanden - G4 Intm Publ G-SMIME NP - 2024 (S/MIME-capable)
    • TSP certificate TSP - G4 PKIo Publ G-SMIME NP - 2024
  • Intermediate Staat der Nederlanden - G4 Intm Publ G-SMIME LP - 2024 (S/MIME-capable)
    • TSP certificate TSP - G4 PKIo Publ G-SMIME LP - 2024
• Root Staat der Nederlanden - G4 Root EUTL G-Sigs - 2024 (Not publicly trusted)
  • Intermediate Staat der Nederlanden - G4 Intm EUTL G-Sigs NP - 2024
    • TSP certificate TSP - G4 PKIo EUTL G-Sigs NP - 2024 (EU Trust List)
  • Intermediate Staat der Nederlanden - G4 Intm EUTL G-Sigs LP - 2024
    • TSP certificate TSP - G4 PKIo EUTL G-Sigs LP - 2024 (EU Trust List)
• Root Staat der Nederlanden - G4 Root Priv G-TLS - 2024 (Not publicly trusted)
  • Intermediate Staat der Nederlanden - G4 Intm Priv G-TLS SYS - 2024
    • TSP certificate TSP - G4 PKIo Priv G-TLS SYS - 2024
• Root Staat der Nederlanden - G4 Root Priv G-Other - 2024 (Not publicly trusted)
  • Intermediate Staat der Nederlanden - G4 Intm Priv G-Other NP - 2024
    • TSP certificate TSP - G4 PKIo Priv G-Other NP - 2024
  • Intermediate Staat der Nederlanden - G4 Intm Priv G-Other LP - 2024
    • TSP certificate TSP - G4 PKIo Priv G-Other LP - 2024
• Root Staat der Nederlanden - G4 Root Priv S-MinDef - 2024 (Not publicly trusted)
  • Intermediate Staat der Nederlanden - G4 Intm Priv S-MinDef NP - 2024
    • TSP certificate Mindef - G4 PKIo Priv S-MinDef NP - 2024
• Root Staat der Nederlanden - G4 Root Priv S-CIBG - 2024 (Not publicly trusted)
  • Intermediate Staat der Nederlanden - G4 Intm Priv S-CIBG NP - 2024
    • TSP certificate CIBG - G4 PKIo Priv S-CIBG NP - 2024
  • Intermediate Staat der Nederlanden - G4 Intm Priv S-CIBG LP - 2024
    • TSP certificate CIBG - G4 PKIo Priv S-CIBG LP - 2024

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

Figure 2: Image containing an overview of the PKIoverheid G4 Publicly-trusted S/MIME root hierarchy

Figure 3: Image containing an overview of the PKIoverheid G4 EUTL signaturs root hierarchy.

Figure 4: Image containing an overview of both the PKIoverheid G4 Private generic and Private server authentication root hierarchies.

Figure 5: Image containing an overview of the PKIoverheid G4 Private specific root hierarchies.

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

• Root certificate TRIAL PKIoverheid Root CA - G3 (Not publicly trusted)
  • Intermediate certificate TRIAL PKIoverheid Organisatie Services CA - G3
    • TSP certificate TRIAL TSP Organisatie Services - G3
    • TSP certificate TRIAL TSP Organisatie Services - G3
  • Intermediate TRIAL PKIoverheid Organisatie Persoon CA - G3
    • TSP certificate TRIAL TSP Organisatie Persoonn CA - G3

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

1.1.1. Compliance with external regulations

For selected CAs which are publicly trusted and are S/MIME capable, PKIoverheid conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates published at the CA/Browser Forum. In the event of any inconsistency between this document regarding said CAs and the normative provisions of those Applicable Requirements, those Applicable Requirements take precedence over this document.

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

Prior to version 5.0, three separate CPS documents were published. These have been combined into a unified CPS and published starting from version 5.0. The original separate CPS documents, including their version histories, can be found at https://cps.pkioverheid.nl. This section will only cover the revision of the current unified CPS.

1.2.2 Relevant Dates

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

1.3 PKI Participants

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

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

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

1.3.1 Certification authorities

The PKIoverheid PA, as well as TSPs issuing end user certificates, can be regarded a Certification Authorities (CA) because both of these parties are able to issue certificates. CAs which issue certificates to end-users are referred to as TSPs in this document.

Both the PKIoverheid PA and PKIoverheid TSPs are described separately in underlying sections.

1.3.1.1 PKIoverheid Policy Authority

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

The responsibilities of the PA PKIoverheid are:

1. further developing and maintaining the framework of underlying standards for PKIoverheid, the Programme of Requirements (PoR), the PKIoverheid Certificate Policy (CP),
2. preparing TSPs in joining the PKIoverheid hierarchy and deciding over their application, and
3. supervising and monitoring the activities of TSPs issuing certificates for the government under the root of PKIoverheid.

TSPs can join the PKIoverheid framework under certain conditions. Participating TSPs are responsible for provisioning core PKI services to subscribers and relying parties, whereas the PA supervises the TSPs to ensure the trustworthiness of PKIoverheid.

The PA PKIoverheid supervises CA management for the Staat der Nederlanden Roots and Intermediate certificates, as well as authority over the Issuing CAs operated by TSPs. In its role managing the PKIoverheid framework, the PA PKIoverheid monitors TSP activities, such as the status of audit certification, audit report reviews, incident report reviews and other requests that are aligned with promoting compliance and security practices. The PA PKIoverheid has ultimate responsibility for the Issuing CAs operated by the TSPs, and control over possible revocation of these certificates.

In practice, this entails:

1. management of the PKIoverheid CP (also referred to as Programme of Requirements);
2. management of Object Identifiers (OIDs), the unique numbers for TSPs and their CPSs;
3. creation and management of key pair and the corresponding root certificate;
4. revoking the root certificate and ad-hoc publication of the Certificate Revocation Lists (CRLs);
5. creation and management of key pairs and the corresponding intermediate (level 2) certificates;
6. revocation of intermediate certificates and ad-hoc publication of the corresponding CRL;
7. preparing and supervising admission of TSPs to PKIoverheid (including creation, issuance and management of TSP CA certificates);
8. supervision of PKIoverheid TSPs;
9. preparation and implementation (including creation, issuance and publication) of new TSP issuing certificates;
10. preparation and implementation of revocation of TSP issuing certificates;
11. periodic and ad-hoc publication of the TSP (level 3) certificates;
12. registration and assessment of audit (ETSI/Webtrust) reports;
13. registration and assessment of (external) threats to PKIoverheid.

KPN B.V. is the supplier of technical services for the Root and Intermediate Certificates for Logius, including maintaining the corresponding Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) responders.

The PKIoverheid Policy Authority is part of Logius, the digital government service of BZK.

1.3.1.2 Trust Service Providers

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

1.3.2 Registration authorities

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

1.3.3 Subscribers

The PA PKIoverheid does not issue certificates to end users, but instead manages the PKIoverheid framework and certificate hierarchies. Subscriber certificates are issued only by participating TSPs. All obligations of TSPs are enforced via legally binding contracts or covenants with Logius. All requirements that are applicable to the operation of TSPs are described in the PKIoverheid Programme of Requirements (PoR).

1.3.4 Relying parties

The relying party is the recipient of a certificate issued within PKIoverheid and acts on the basis of trust in the certificate. The relying party is obliged to check the validity of the full chain of certificates through to the source (root certificate) on which trust is placed.

1.3.5 Other participants

Other participants in PKIoverheid are:

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

1.4 Certificate Usage

1.4.1 Permitted Certificate Usage

Within PKIoverheid, different types of certificates are defined at four levels within its hierarchies, which are:

1. Root certificate;
2. Intermediate certificate;
3. TSP certificate;
4. End entity 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 entity certificate is issued by the TSPs. End entity certificates can be used in different functional domains and with different purposes:

• Root: Staat der Nederlanden Root CA - G3
  • Intermediate: Staat der Nederlanden Burger CA - G3 and underlying TSP certificate(s)
    • End Entity: Authenticity
    • End Entity: Non-repudiation
    • End Entity: Confidentiality
  • Intermediate: Staat der Nederlanden Organisatie Services CA - G3 and underlying TSP certificate(s)
    • End Entity: Authenticity
    • End Entity: Non-repudiation
    • End Entity: Confidentiality
  • Intermediate: Staat der Nederlanden Organisatie Persoon CA - G3 and underlying TSP certificate(s)
    • End Entity: Authenticity
    • End Entity: Non-repudiation
    • End Entity: Confidentiality
  • Intermediate: Staat der Nederlanden Autonome Apparaten CA - G3 and underlying TSP certificate(s)
    • End Entity: Authenticity
    • End Entity: Confidentiality
    • End Entity: Combination
  • Intermediate: Staat der Nederlanden Citizen CA - G3 2023 and underlying TSP certificate(s)
    • End Entity: Authenticity
    • End Entity: Non-repudiation
    • End Entity: Confidentiality
  • Intermediate: Staat der Nederlanden Organization Services CA - G3 2023 and underlying TSP certificate(s)
    • End Entity: Authenticity
    • End Entity: Non-repudiation
    • End Entity: Confidentiality
  • Intermediate: Staat der Nederlanden Organization Person CA - G3 2023 and underlying TSP certificate(s)
    • End Entity: Authenticity
    • End Entity: Non-repudiation
    • End Entity: Confidentiality
  • Intermediate: Staat der Nederlanden S/MIME CA - G3 2023 and underlying TSP certificate(s)
    • End Entity: Sponsor-validated (strict)
    • End Entity: Organization-validated (strict)
    • End Entity: Individual-validated (strict)
• Root: Staat der Nederlanden Private Root CA - G1
  • Intermediate: Staat der Nederlanden Private Personen CA - G1 and underlying TSP certificate(s)
    • End Entity: Authenticity
    • End Entity: Non-repudiation
    • End Entity: Confidentiality
  • Intermediate: Staat der Nederlanden Private Services CA - G1 and underlying TSP certificate(s)
    • End Entity: Authenticity
    • End Entity: Confidentiality
    • End Entity: Server Authentication
• Root: TRIAL PKIoverheid Root CA - G3
  • Intermediate: TRIAL PKIoverheid Organisatie Persoon CA - G3 and underlying TSP certificate(s)
    • End Entity: Authenticity
    • End Entity: Non-repudiation
    • End Entity: Confidentiality
  • Intermediate: TRIAL PKIoverheid Organisatie Services CA - G3 and underlying TSP certificate(s)
    • End Entity: Authenticity
    • End Entity: Confidentiality
    • End Entity: Server Authentication
• Root: Staat der Nederlanden - G4 Root Publ G-SMIME - 2024
  • Intermediate: Staat der Nederlanden - G4 Intm Publ G-SMIME NP - 2024 and underlying TSP certificate(s)
    • End Entity: Individual Validated Signing-only (strict)
    • End Entity: Individual Validated Key Management (strict)
    • End Entity: Individual Validated Dual Use (strict)
    • End Entity: Sponsor Validated Signing-only (strict)
    • End Entity: Sponsor Validated Key Management (strict)
    • End Entity: Sponsor Validated Dual Use (strict)
  • Intermediate: Staat der Nederlanden - G4 Intm Publ G-SMIME LP - 2024 and underlying TSP certificate(s)
    • End Entity: Organization Validated Signing-only (strict)
    • End Entity: Organization Validated Key Management (strict)
    • End Entity: Organization Validated Dual Use (strict)
• Root: Staat der Nederlanden - G4 Root EUTL G-Sigs - 2024
  • Intermediate: Staat der Nederlanden - G4 Intm EUTL G-Sigs NP - 2024 and underlying TSP certificate(s)
    • End Entity: Individual Validated Non-repudiation (eSignature)
    • End Entity: Regulated Profession Validated Non-repudiation (eSignature)
    • End Entity: Sponsor Validated Non-repudiation (eSignature)
    • End Entity: Regulated Profession with Sponsor Validated Non-repudiation (eSignature)
  • Intermediate: Staat der Nederlanden - G4 Intm EUTL G-Sigs LP - 2024 and underlying TSP certificate(s)
    • End Entity: Organization Validated Non-repudiation (eSeal)
• Root: Staat der Nederlanden - G4 Root Priv G-TLS - 2024
  • Intermediate: Staat der Nederlanden - G4 Intm Priv G-TLS SYS - 2024 and underlying TSP certificate(s)
    • End Entity: Organization Validated Server Authentication
• Root: Staat der Nederlanden - G4 Root Priv G-Other - 2024
  • Intermediate: Staat der Nederlanden - G4 Intm Priv G-Other NP - 2024 and underlying TSP certificate(s)
    • End Entity: Individual Validated Authenticity (strict)
    • End Entity: Individual Validated Authentication
    • End Entity: Regulated Profession Validated Authenticity (strict)
    • End Entity: Regulated Profession Validated Authentication
    • End Entity: Sponsor Validated Authenticity (strict)
    • End Entity: Sponsor Validated Authentication
    • End Entity: Regulated Profession with Sponsor Validated Authenticity (strict)
    • End Entity: Regulated Profession with Sponsor Validated Authentication
  • Intermediate: Staat der Nederlanden - G4 Intm Priv G-Other LP - 2024 and underlying TSP certificate(s)
    • End Entity: Organzation Validated Authenticity (strict)
    • End Entity: Organzation Validated Authentication
• Root: Staat der Nederlanden - G4 Root Priv S-MinDef - 2024
  • Intermediate: Staat der Nederlanden - G4 Intm Priv S-MinDef NP - 2024 and underlying TSP certificate(s)
    • End Entity: Sponsor Validated Authenticity (strict)
    • End Entity: Sponsor Validated Authentication
• Root: Staat der Nederlanden - G4 Root Priv S-CIBG - 2024
  • Intermediate: Staat der Nederlanden - G4 Intm Priv S-CIBG NP - 2024 and underlying TSP certificate(s)
    • End Entity: Individual Validated Authenticity (strict)
    • End Entity: Individual Validated Authentication
    • End Entity: Individual Validated Confidentiality
    • End Entity: Regulated Profession Validated Authenticity (strict)
    • End Entity: Regulated Profession Validated Authentication
    • End Entity: Regulated Profession Validated Confidentiality
    • End Entity: Sponsor Validated Authenticity (strict)
    • End Entity: Sponsor Validated Authentication
    • End Entity: Sponsor Validated Confidentiality
    • End Entity: Regulated Profession with Sponsor Validated Authenticity (strict)
    • End Entity: Regulated Profession with Sponsor Validated Authentication
    • End Entity: Regulated Profession with Sponsor Validated Confidentiality
  • Intermediate: Staat der Nederlanden - G4 Intm Priv S-CIBG LP - 2024 and underlying TSP certificate(s)
    • End Entity: Organzation Validated Authenticity (strict)
    • End Entity: Organzation Validated Authentication
    • End Entity: Organzation Validated 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 PKIoverheid 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 Dutch 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

For questions or issues with PKIoverheid end entity certificates (level 4) contact the TSP that issued it. Contact details are found in their respective CPSs.

For questions or issues relating to Root CAs, Intermediate CAs, TSP CAs, their associated OCSP responders and/or CRLs, contact Logius through the contact information below.

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

1.5.3 The person determining policy documents suitability for Certificate Policies

The PA PKIoverheid does not have its own general Certificate Policy.

1.5.4 Policy approval procedures

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

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

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

1.6 Definitions and abbreviations

1.6.1 Definitions

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

1.6.2 Acronyms

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

2 Publication and electronic repository responsibilities

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

2.1 Electronic repository

PKIoverheid information is published in the following locations:

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

Applicable requirements from the CA/Browser Forum can be found in the following locations:

• The Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates at https://cabforum.org/working-groups/smime/requirements/;
• The Network and Certificate System Security Requirements at https://cabforum.org/working-groups/netsec/requirements/.

2.2 Publication certificate information

The location of PKIoverheid certificate information can be found in the table below.

2.3 Time or frequency of publication

PKIoverheid information is published with the following frequency:

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

2.4 Access controls to publication

Published PKIoverheid information is public in nature and freely accessible.

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

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

3 Identification and Authentication

3.1 Naming

3.1.1 Types of names

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

• countryName
• organizationName
• commonName

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

• organizationIdentifier

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

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

3.1.2 Need for names to be meaningful

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

3.1.3 Pseudonyms

PKIoverheid does not permit the use of pseudonyms in certificates.

3.1.4 Rules for interpreting various name forms

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

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

3.1.5 Uniqueness of names

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

3.1.6 Recognition, authentication and role of trademarks

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

3.2 Initial identity validation

3.2.1 Initial Registration Process

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

3.2.2 Authentication of organizational identity

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

• that the TSP is an existing organization listed in the Dutch National Trade Register (called “Nieuw Handelregister” in Dutch, or NHR), an organizational entity that forms part of an existing organization listed in the NHR, or a trade name of either;
• that the name of the organization and country name registered by the TSP to be incorporated in the certificate are correct and complete and that the applicant is authorized to represent the organization;
• the presence of the relevant registration information of the prospective TSP, with the corresponding evidence (excerpt from the Chamber of Commerce, etc.) which must be original and must not be older than 13 months.

If the subscriber is a government organization absent in the NHR, the Register van Overheidsorganisaties is consulted instead.

Note: If the participating party has existed for less than three years and does not appear in the latest version of the registration sources listed above, the identity and validity of the prospective TSP may be established using a parent company or ministry that is registered in the NHR or the Staatsalmanak.

3.2.3 Authentication of individual identity

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

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

3.2.4 Non-verified subscriber information

No stipulation.

3.2.5 Validation of authority

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

1. Operational contact;
2. Authorized signatory.

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

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

Initial contacts per TSP have to be approved by an Authorized Representative 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.

Note: Only signed signatory as listed in the PKIoverheid authorization list can request new issuing certificates or revocation of issuing certificates.

3.2.6 Criteria for interoperation

Cross-signing of certificates is not allowed within PKIoverheid.

3.3 Identification and authentication for Re-Key Requests

3.3.1 Identification and authentication for routine re-key

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

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

3.3.2 Identification and authentication for re-key after revocation

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

3.4 Identification and authentication for Revocation Requests

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

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

4 Certificate Life-Cycle Operational Requirements

4.1 Certificate Application

4.1.1 Who can submit a certificate application

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

4.1.2 Enrollment process and responsibilities

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

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

4.2 Certificate application processing

4.2.1 Performing Identification and Authentication Functions

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

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

4.2.2 Approval or Rejection of Certificate Applications

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

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

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

4.2.3 Time to Process Certificate Applications

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

4.3 Certificate issuance

4.3.1 CA actions during certificate issuance

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

All ceremonies follow these general steps:

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

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

4.3.2 Notification to subscriber by the CA of issuance of Certificate

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

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

4.4 Certificate acceptance

4.4.1 Conduct constituting certificate acceptance

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

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

4.4.2 Publication of the certificate by the CA

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

4.4.3 Notification of certificate issuance by the CA to other Entities

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

4.5 Key Pair and Certificate Usage

4.5.1 Subscriber private key and certificate usage

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

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

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

4.5.2 Relying party public key and certificate usage

No stipulation.

4.6 Certificate renewal

4.6.1 Circumstance for certificate renewal

PKIoverheid does not support certificate renewal.

4.6.2 Who may request renewal

Not Applicable.

4.6.3 Processing certificate renewal requests

Not Applicable.

4.6.4 Notification of new certificate issuance to subscriber

Not Applicable.

4.6.5 Conduct constituting acceptance of a renewal certificate

Not Applicable.

4.6.6 Publication of the renewal certificate by the CA

Not Applicable.

4.6.7 Notification of certificate issuance by the CA to other entities

Not Applicable.

4.7 Certificate re-key

Not Applicable.

4.7.1 Circumstance for certificate re-key

PKIoverheid does not support Certificate re-key.

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

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

4.8.1 Circumstance for certificate modification

Certificate modification may only be performed when included information in a certificate changes or is out of date. Examples are a change in the name of a TSP as included in the certificate, or if included attributes and/or extensions lead to issues with conflicting policies.

4.8.2 Who may request certificate modification

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

4.8.3 Processing certificate modification requests

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

4.8.4 Notification of new certificate issuance to subscriber

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

4.8.5 Conduct constituting acceptance of modified certificate

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

4.8.6 Publication of the modified certificate by the CA

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

4.8.7 Notification of certificate issuance by the CA to other entities

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

4.9 Certificate revocation and suspension

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

4.9.1 Circumstances for revocation

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

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

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

Compromised Private Key

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

• the PKIoverheid PA obtains verifiable evidence that the private key corresponding to the public key in a certificate suffered a key compromise;
• the PKIoverheid PA is made aware of a demonstrated or proven method that exposes the private key corresponding to the public key in a certificate to compromise;
• there is clear evidence that the specific method used to generate the private key corresponding to the public key in a certificate was flawed; or
• the PKIoverheid PA is made aware of a demonstrated or proven method that can easily compute the private key based corresponding to the public key in a certificate (such as a Debian weak key, see 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 CVE-2008-0166); or
• after the request by a TSP for this reason the PKIoverheid PA revokes the TSP’s Issuing certificate.

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

Otherwise, the keyCompromise revocation reason will not be used.

Changed affiliation

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

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

Otherwise, the affiliationChanged revocation reason is not used.

Certificate superseded

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

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

Otherwise, the superseded revocation reason will not be used.

Cessation of operation

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

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

Otherwise, the cessationOfOperation revocation reason will not be used.

Privilege withdrawn

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

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

Otherwise, the privilegeWithdrawn revocation reason will not be used.

4.9.2 Who can request revocation

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

TSP signed signatories can request revocation of their issuing certificates.

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

4.9.3 Procedure for revocation request

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

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

In case of major incidents which require distrust of a root certificate, revocation of a level 2 intermediate CA or multiple TSP (issuing) CAs, a careful assessment process is followed. The incident handling team will perform this assessment and will initiate any activities that may ensue from this. The PA strives to comply with the deadlines set by the most stringent policy (either external or internal).

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

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

4.9.4 Revocation request grace period

No stipulation.

4.9.5 Time within which CA must process the revocation request

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

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

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

4.9.6 Revocation checking requirement for relying parties

No stipulation.

4.9.7 CRL issuance frequency

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

4.9.8 Maximum latency for CRLs

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

4.9.9 On-line revocation/status checking availability

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

4.9.10 On-line revocation checking requirements

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

The PKIoverheid OCSP responder updates its information

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

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

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

4.9.11 Other forms of revocation advertisements available

No other form of revocation advertisement is available.

4.9.12 Special requirements related to key compromise

See Section 4.9.1.

4.9.13 Circumstances for suspension

Suspension of certificates is not supported within PKIoverheid.

4.9.14 Who can request suspension

Suspension of certificates is not supported within PKIoverheid.

4.9.15 Procedure for suspension request

Suspension of certificates is not supported within PKIoverheid.

4.9.16 Limits on suspension period

Suspension of certificates is not supported within PKIoverheid.

4.10 Certificate Status Services

4.10.1 Operational characteristics

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

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

4.10.2 Service availability

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

4.10.3 Optional features

No stipulation.

4.11 End of subscription

There is no formal process for TSPs to request the withdrawal of an Issuing CA or their withdrawal from the PKIoverheid hierarchy. Arrangements are made between the PA PKIoverheid and the TSP to ensure continuity of services for existing subscribers. The PA PKIoverheid and TSPs ensure there are sufficient business continuity contigency plans are in place for the dissemination and revocation services for subscribers.

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

4.12 Key escrow and recovery

4.12.1 Key escrow and recovery policy and practices

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

4.12.2 Session key encapsulation and recovery policy and practices

No stipulation.

5 Facility Management, Operational, and Physical Controls

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

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

5.1 Physical controls

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

5.1.1 Site location and construction

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

5.1.2 Physical access

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

5.1.3 Power and air conditioning

No stipulation.

5.1.4 Water exposures

No stipulation.

5.1.5 Fire prevention and protection

No stipulation.

5.1.6 Media storage

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

5.1.7 Waste disposal

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

5.1.8 Off-site backup

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

5.2 Procedural controls

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

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

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

5.2.1 Trusted roles

PKIoverheid recognizes the following trusted roles:

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

5.2.2 Number of persons required per task

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

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

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

5.2.3 Identification and authentication for each role

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

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

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

5.2.4 Roles requiring separation of duties

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

5.3 Personnel Security Controls

5.3.1 Qualifications, experience, and clearance requirements

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

5.3.2 Background check procedures

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

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

5.3.3 Training requirements

No stipulation.

5.3.4 Retraining frequency and requirements

No stipulation.

5.3.5 Job rotation frequency and sequence

No stipulation.

5.3.6 Sanctions for unauthorized actions

No stipulation.

5.3.7 Independent contractor requirements

No stipulation.

5.3.8 Documentation supplied to personnel

No stipulation.

5.4 Audit logging procedures

5.4.1 Types of events recorded

The PKIoverheid PA records the following events:

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

Additionally, PKIoverheid Key Management records the following events:

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

All log records include at least the following elements:

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

5.4.2 Frequency of processing log

Logs of all online CA systems are processed through an automated mechanisms under the control of personnel assigned to an applicable Trusted Role.

Unauthorized changes to CA Infrastructure as well as many other critical and non-critical security events have been defined in the log monitoring environment. Detected security events are communicated with personnel assigned to an applicable Trusted Role in real-time.

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

5.4.3 Retention period for audit log

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

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

5.4.4 Protection of audit log

No stipulation.

5.4.5 Audit log backup procedures

No stipulation.

5.4.6 Audit collection system (internal vs. external)

No stipulation.

5.4.7 Notification to event-causing subject

No stipulation.

5.4.8 Vulnerability assessments

The PKIoverheid PA performs an annual Risk Assessment that:

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

5.5 Records archival

5.5.1 Types of records archived

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

In addition to this, the following information is archived:

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

5.5.2 Retention period for archive

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

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

5.5.3 Protection of archive

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

5.5.4 Archive backup procedures

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

5.5.5 Requirements for time-stamping of records

No stipulation.

5.5.6 Archive collection system (internal or external)

No stipulation.

5.5.7 Procedures to obtain and verify archive information

No stipulation.

5.6 Key changeover

Private Keys corresponding to Public Keys in PKIoverheid Root, Intermediate, or TSP Issuing certificates normally are not reused once the term of validity has expired, or once the corresponding certificate has been revoked. When certificates are renewed, the key pair is also renewed. Only in rare circumstances key re-use will be allowed; see Section 4.7.

5.7 Compromise and disaster recovery

5.7.1 Incident and compromise handling procedures

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

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

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

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

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

5.7.3 Entity private key compromise procedures

See Section 4.9.1.

5.7.4 Business continuity capabilities after a disaster

See Section 5.7.2.

5.8 CA or RA termination

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

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

1. All TSPs, end-entity certificate subcribers, and other relying parties within PKIoverheid, shall be informed at least six months before the service ends.
2. All certificates that are issued after announcement of termination of the service WILL NOT contain a NotAfter date which is later than the planned termination date of PKIoverheid.
3. When the service ends, all certificates that are still valid will be revoked.
4. On the termination date, PKIoverheid ceases to distribute certificates and CRLs.

If the Ministry of the Interior and Kingdom Relations decides to transfer the PKIoverheid service to a different organization, all TSPs, end-entity certificate subcribers, and other relying parties within PKIoverheid, will be informed of this transfer at least 3 months in advance. The new organization will transfer the provisions from this CPS to its own CPS.

6 Technical Security Controls

6.1 Key pair generation and installation

6.1.1 Key pair generation

PA Key pairs are generated during Key Ceremonies. The computers used during Key Ceremonies are not connected to any network. All information for the Key Ceremony is introduced to the computer via removable media storage devices. The computers used for Key Ceremonies are not used for any other purpose, and when they are not in use they are stored away in secure vaults subject to access controls.

The Key Ceremonies comply with all stipulations in Section 6.1.1 of the TBR.

6.1.2 Private key delivery to subscriber

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

6.1.3 Public key delivery to certificate issuer

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

6.1.4 CA public key delivery to relying parties

No stipulation.

6.1.5 Key sizes

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

6.1.6 Public key parameters generation and quality checking

No stipulation.

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

See keyUsage field descriptions in Section 7.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic module standards and controls

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

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

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

6.2.3 Private key escrow

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

6.2.4 Private key backup

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

6.2.5 Private key archival

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

6.2.6 Private key transfer into or from a cryptographic module

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

6.2.7 Private key storage on cryptographic module

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

6.2.8 Method of activating private key

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

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

6.2.9 Method of deactivating private key

No stipulation.

6.2.10 Method of destroying private key

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

6.2.11 Cryptographic Module Rating

See Section 6.2.1.

6.3 Other aspects of key pair management

6.3.1 Public key archival

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

6.3.2 Certificate operational periods and key pair usage periods

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

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

6.4 Activation data

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

6.4.1 Activation data generation and installation

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

6.4.2 Activation data protection

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

6.4.3 Other aspects of activation data

No stipulation.

6.5 Computer security controls

6.5.1 Specific computer security technical requirements

PKIoverheid Key Management has implemented all technical computer security requirements as described the Network and Certificate System Security Requirements (NetSec) CA/Browser Forum document. This includes, but is not limited to, hardening measures as described in NetSec Section 1.2, access control mechanisms as described in NetSec Section 2, and technical log monitoring requirements as described in NetSec Section 3.1.

In addition to this, information security practices for all CA systems, including computer security technical requirements, are ISO 27001 certified.

6.5.2 Computer security rating

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

6.6 Life cycle technical controls

6.6.1 System development controls

Changes to information systems are implemented using a formal change management process which complies with Section 1.3 of the Network and Certificate System Security Requirements (NetSec) CA/Browser Forum document. The change process includes testing on a separate environment for development purposes, as well as acceptance testing on another separate environment.

6.6.2 Security management controls

The PKIoverheid team has implemented all security management controls as described the Network and Certificate System Security Requirements (NetSec) CA/Browser Forum document. This includes, but is not limited to, change management as described in NetSec Section 1.3, access management as described in NetSec Section 2.2, audit log management as described in NetSec Section 3.2, and Vulnerability and Patch Management as described in NetSec Section 4.

In addition to this, information security practices for all CA systems, including computer security management controls, are ISO 27001 certified.

6.6.3 Life cycle security controls

The PKIoverheid team has implemented all security life-cycle controls as described in the Network and Certificate System Security Requirements (NetSec) CA/Browser Forum document. This includes, but is not limited to, change management as decribed in NetSec Section 1.3.

In addition to this, information security practices for all CA systems, including life cycle security controls, are ISO 27001 certified.

6.7 Network security controls

The PKIoverheid team has implemented all network security controls as described the Network and Certificate System Security Requirements (NetSec) CA/Browser Forum document. This includes, but is not limited to, hardening measures as described in NetSec Section 1.1 and 1.2, access control mechanisms as described in NetSec Section 2, and technical log monitoring requirements as described in NetSec Section 3.1.

In addition to this, information security practices for all CA systems, including network security controls, are ISO 27001 certified.

6.8 Time-stamping

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

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

7 Certificate and CRL, and OCSP profiles

7.1 Certificate profile

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

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

7.1.1 Version number(s)

See Section 7.1.

7.1.2 Certificate extensions

See Section 7.1.

7.1.3 Algorithm object identifiers

See Section 7.1.

7.1.4 Name forms

See Section 7.1 for a complete overview.

The subject:commonName value of every G4 CA is based on a the following naming convention:

• Root certificatess: (Staat der Nederlanden - G4xx Root )(EUTL |Publ |Priv )(G-|S-)(Sigs |SMIME |TLS | Other |CIBG |MinDef |ILT )[R-OCSP ](- yyyy)[-nn]
• Intermediate certificates: (Staat der Nederlanden - G4xx Intm )(EUTL |Publ |Priv )(G-|S-)(Sigs |SMIME |TLS |CIBG |MinDef |ILT )((R-|N-|L-|S-)OCSP |SYS |LP |NP )(- yyyy)[-nn]
• TSP certificates: (max 21-character TSP name)(- PKIo G4xx )(EUTL |Publ |Priv )(G-|S-)(Sigs |SMIME |TLS |CIBG |MinDef |ILT )((R-|N-|L-|S-)OCSP |SYS |LP |NP )(- yyyy)[-nn]

Legend:

• [xx] = Optional; not used by default: reserved for future qualifiers (e.g. PQ algorithms for).
• (EUTL|Publ|Priv) = This is the “trust” qualifier, meaning a CA with a trust anchor in the EUTL, publicly trusted by the browser parties, or privately trusted.
• (G-|S-) = Identifier of either a Generic or a Specific hierarchy.
• (Sigs|SMIME|TLS|Other|CIBG|MinDef|ILT) = This qualifier indicates what the hierarchy is meant for: generic Signatures, S/MIME, of TLS, Other, or specific hierarchies for CIBG, Defensie, or ILT.
• (R-OCSP|N-OCSP|L-OCSP|S-OCSP|SYS|LP|NP) = This is the type qualifier. LP, NP, and SYS are used for the “Logical Person”, “Natural Person, and”System” (devices) usage domains; OCSP is self-exlpainatory, and the (R-|L-|N-|S-) prefixes are used for the LP, NP, and SYS CA usage domains where the Delegated OCSP Responder certificates can exist.
• (yyyy) = Year of certificate issuance.
• [-nn] = Optional two-digit sequence number (begins with 01, or 02 when the number was initially omitted) within the same year. This allows for enough space for short-lived certificates. The meaning of the sequence number can differ per use case.

7.1.5 Name constraints

See Section 7.1.

7.1.6 Certificate policy object identifier

See Section 7.1.

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

7.1.7 Usage of Policy Constraints extension

The policyConstraints extension is not used within PKIoverheid.

7.1.8 Policy qualifiers syntax and semantics

See Section 7.1.

7.1.9 Processing semantics for the critical Certificate Policies extension

No stipulation.

7.2 CRL profile

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

7.2.1 Version number(s)

See Section 7.2.

7.2.2 CRL and CRL entry extensions

See Section 7.2.

7.3 OCSP profile

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

7.3.1 Version number(s)

See Section 7.3.

7.3.2 OCSP extensions

If applicable, see Section 7.3.

8 Compliance Audit and Other Assessment

8.1 Frequency or circumstances of assessment

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

The PA PKIoverheid actively monitors the changes in the WebTrust Principles that affect this CPS. The PA PKIoverheid also actively monitors changes in the S/MIME Baseline Requirements of the CA / Browser Forum that affect this CPS and the Programme of Requirements of PKIoverheid. The impact of these changes on the CPS and PoR of PKIoverheid are assessed and, if deemed necessary, incorporated in the PoR and/or this CPS.

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

8.2 Identity/qualifications of assessor

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

8.3 Assessor’s relationship to assessed entity

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

8.4 Topics covered by assessment

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

1. WebTrust Principles and Criteria for Certification Authorities Framework (WTCA)
   • Assesses against the Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Certificates
2. WebTrust Principles and Criteria for Certification Authorities - S/MIME Framework (WTSM)
   • Assesses against the Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates
3. WebTrust Principles and Criteria for Certification Authorities - SSL Baseline with Network Security Framework (WTBR)
   • Assesses against the Network and Certificate System Security Requirements

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

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

8.5 Actions taken as a result of deficiency

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

8.6 Communicating of results

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

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

8.7 Self-audits

No stipulation.

9 Other Business and Legal Matters

9.1 Fees

9.1.1 Certificate issuance or renewal fees

No stipulation.

9.1.2 Certificate access fees

All PKIoverheid Root, Root, and OCSP SIgning certificates contain a reference to this CPS. No fee is charged for consulting these certificates or the information referred to. This applies to:

• consulting the certificates,
• consulting the revocation status information (CRLs or OCSP),
• consulting the Programme of Requirements: Certificate Policies, and
• consulting this CPS.

9.1.3 Revocation or status information access fees

No stipulation.

9.1.4 Fees for other services

No stipulation.

9.1.5 Refund policy

No stipulation.

9.2 Financial responsibility

9.2.1 Insurance coverage

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

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

9.2.2 Other assets

No stipulation.

9.2.3 Insurance or warranty coverage for end-entities

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

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

9.3 Confidentiality of business information

9.3.1 Scope of confidential information

No stipulation.

9.3.2 Information not within the scope of confidential information

No stipulation.

9.3.3 Responsibility to protect confidential information

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

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

9.4 Privacy of personal information

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

9.4.1 Privacy plan

Not applicable.

9.4.2 Information treated as private

Not applicable.

9.4.3 Information not deemed private

Not applicable.

9.4.4 Responsibility to protect private information

Not applicable.

9.4.5 Notice and consent to use private information

Not applicable.

9.4.6 Disclosure pursuant to judicial or administrative process

Not applicable.

9.4.7 Other information disclosure circumstances

Not applicable.

9.5 Intellectual property rights

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

9.6 Representations and warranties

9.6.1 CA representations and warranties

No stipulation.

9.6.2 RA representations and warranties

No stipulation.

9.6.3 Subscriber representations and warranties

No stipulation.

9.6.4 Relying party representations and warranties

No stipulation.

9.6.5 Representations and warranties of other participants

No stipulation.

9.7 Disclaimers of warranties

See Section 9.2.

9.8 Limitations of Liability

See Section 9.2.

9.9 Indemnities

See Section 9.2.

9.10 Term and termination

9.10.1 Term

This CPS is valid as from the date of entry into force. The CPS is valid for the period of time that the services of PKIoverheid continue or until the CPS is replaced by a newer version. The latest version can always be found in the electronic repository mentioned in Section 2.1.

9.10.2 Termination

No stipulation.

9.10.3 Effect of termination and survival

No stipulation.

9.11 Individual notices and communications with participants

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

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

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

9.12 Amendments

Within PKIoverheid several different policy documents exist:

1. this CPS,
2. the CP for PKIoverheid TSPs (“Program of Requirements”), and
3. the Policy and Registration of OIDs under the PKIoverheid arc.

Due to the nature of these documents, each change must be properly administered through a set procedure(s), i.e. change management. This process provides authorized users with access to a comprehensive history of document changes, enables them to view and participate in discussions related to changes, and allows them to view, track, and compare previous versions as needed. The PA uses GitHub as the tool for this purpose, and any changes to its configuration (“maintenance”) are also managed under change control.

9.12.1 Procedure for amendment

Procedures for amendments differ between the three documents and are described in the following subsections.

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

9.12.1.2 Program of Requirements for PKIoverheid TSPs

9.12.1.2.1 Involved parties

1. Within the PKIoverheid framework the following parties are involved in Change Management of the Programme of Requirements PKIoverheid (the “PoR”):
   • Policy Authority PKIoverheid (“PA”);
   • Trust Service Providers participating in the PKIoverheid framework (“TSPs”);
   • An Official appointed by the Ministry of the Interior and Kingdom Relations (“BZK” and/or “Official”);
2. Two Councils convene to discuss proposed changes:
   • PKIoverheid Change Council
   • PKIoverheid Framework Council
3. Both Councils are comprised of a delegation of the PA and participating TSPs. At the discretion of the PA, external experts may be invited to join the Change Council on a temporary or permanent basis;
4. Auditors of participating TSPs may join the deliberations of the Change Council and/or Framework Council as observer only.

9.12.1.2.2 Decision-making

The Ministry of the Interior and Kingdom Relations has final responsibility for the PKIoverheid framework and enforces the Programme of Requirements PKIoverheid. The process of decision making is available to all parties involved and is as follows:

1. The PA assesses all submitted change requests for applicability, suitability and priority, and may reject change requests outright;
2. The PA serves as the chair of the Change and Framework Council meetings;
3. During the Change Council The TSPS have an opportunity to request that changes are either approved, modified, delayed or rejected by the PA. It is up to the PA in her delegated role as owner of PKIoverheid to accept or refuse these requests.
4. The output of the Framework Council is which finalized change requests are to be included in the upcoming version of the PoR, and any applicable effective date(s) for each;
5. A formal signature is required by both the director of Logius Directorate under which PKIoverheid resides and the Director of the directorate of Ministry of the Interior and Kingdom Relations under which Logius resides. For expedited changes the PA grants approval, and such changes will be incorporated into the next (scheduled) version of the PoR. In the mean time, these changes will be effective immediately or on the effective date set by the PA and will be published on the same website as the PoR;
6. BZK and/or the PA reserves the right to make changes to the PoR autonomously in the context of an (imminent) incident, emergency or crisis.

9.12.1.2.3 Frequency

1. The Change Council is held monthly. The PA may convene the Council more frequently to discuss high impact, urgent and/or complex change requests;
2. The Framework Council discusses changes that have been approved for at least 4 weeks so that the TSPs have sufficient time to determine the impact of the proposed changes ;
3. A new version of the PoR is published every 6 months, however the PA may decide to expedite or to postpone a release if deemed necessary.

9.12.1.2.4 Compliance by the TSPs

1. TSPs must comply with the content and effective dates of:
   • changes approved and published by the official appointed by the Ministry of the Interior and Kingdom Relations;
   • any current expedited changes.
2. If a TSP is unable to comply with (the effective date of) a new or changed requirement, the PA must be notified as soon as possible. Depending on the issue, the PA might be able to grant the TSP an dispensation on a PoR requirement or part thereof;
3. The PA assesses the request and grants or rejects the dispensation. The auditor of the TSP will receive a copy of this message.

9.12.1.2.5 Transparency

1. A Github repository is provided by the PA to log, discuss, monitor, reject and apply change requests to the Programme of Requirements;
2. All change requests must be submitted to the designated repository. If an alternate submission method is used, the PA will enter them into the repository and inform the requestor accordingly;
3. Members of the Change Council are strongly encouraged to monitor open change requests and to participate in online and offline conversations regarding the subject;
4. Access to this repository is restricted to the PA and members of the Change and Framework Councils;
5. TSPs must ensure access to the repository for at least two stakeholders per TSP. TSPs are able to request accounts from the PA for these stakeholders. Access for more than two stakeholders per TSP is on the basis of “fair use” and is up to the discretion of the PA;
6. The PA maintains a working draft (“master branch”) containing all changes approved by the Change Council. As input for Framework Council meetings, the PA compiles a review draft (“Release Candidate, RC”) including selected changes. If needed, multiple RCs can be created (for instance for editorials);
7. After approval of the RC or RCs by the Framework Council, these are submitted to BZK for ratification;
8. After ratification, the PA publishes a new Programme of Requirements version on the PKIoverheid website at https://cp.pkioverheid.nl.

9.12.1.2.6 Change procedures

1. The following parties may submit change requests:
   1. the Official from the Ministry of the Interior and Kingdom Relations;
   2. the PA PKIoverheid (PA);
   3. TSPs within the PKI for the government.
2. The PA can submit change requests based on the input from end users or other stakeholders. This will be clearly indicated in the change request.
3. Any member of the Change Council is permitted to draft text proposals for the Change, however, the PA retains the right to modify, or reject such proposals (see also 9.12.1.2.2 bullet 1);
4. A change may be categorised as:
   • a technical change to modify application configuration having no impact to the contents of the document itself;
   • an editorial change to modify formatting/layout, correction of typographical errors, links and references, punctuation changes and grammar/orthographic corrections, provided none of the changes alter the meaning of the text;
   • an expedited change to prevent, or during, (security) incidents, emergencies or crises, repair errors, omissions and/or other contradictions within and with external policies;
   • a regular change if none of the previous categories apply.
5. Depending on its category, a different procedure is to be followed (see subsections).

9.12.1.2.6.1 Regular change procedure

1. A Regular Change Request is discussed and ultimately approved during a minimum of two Change Council meetings at least one week apart;
2. It is included in the upcoming Framework Council meeting to decide inclusion in the upcoming version of the PoR, and if required, alternate effective date(s).

9.12.1.2.6.2 Editorial change procedure

1. An Editorial Change Requests will not be discussed during any Change Council or Framework Council meetings unless requested by a participant. A separate Pull Request is offered for TSPs if they would like to review these editorial changes and this will be included in the upcoming Framework Council meeting.

9.12.1.2.6.3 Expedited change procedure

1. An Expedited change temporarily bypasses the standard approval structure, therefore the PA must provide justification for employing the expedited change process and explain why the regular procedure is unsuitable;
2. The PA informs all members of the Change and Framework Councils and the Official appointed by the Ministry of the Interior and Kingdom Relations by email with its intent and justification to publish an expedited change, along with a link to a GitHub Pull Request which offers a redline version of the change request itself;
3. Members of the Change and Framework Councils and the Official have at least one week to submit feedback to the content and/or effective date of this change, preferably via the Pull Request that the PA has sent;
4. Any feedback will be taken into consideration by the PA PKIoverheid, which may result in an updated Change Request. If justified, the PA may however decide to ignore the objections;
5. The PA publishes the change on the PoR website and notifies all members of the Change and Framework Councils and the Official. The TSPs must comply to the content and the effective date of the published change;
6. The Change is included in the next version of the PoR. Upon inclusion in the next version/release, the requirement text will be removed from the PoR website landing page.

9.12.1.2.6.4 Technical change procedure

Changes marked as maintenance affect only configuration and automation changes, such as syntax linting, link checking and PDF exports. Because these do not alter the contents of the document, only approval from a second engineer within the PKIoverheid team is needed. PA or Framework Council approval is not needed.

9.12.1.3 Registration of PKIoverheid OIDs

The PKIoverheid PA is itself fully responsible for maintaining and decision making regarding the PKIoverheid OID naming arc. More information about this can be found at https://oid.pkioverheid.nl

9.12.2 Notification mechanism and period

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

9.12.3 Circumstances under which OID must be changed

No stipulation.

9.13 Dispute resolution provisions

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

9.14 Governing law

Dutch law applies.

9.15 Compliance with Applicable Law

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

9.16 Miscellaneous provisions

9.16.1 Entire agreement

No stipulation.

9.16.2 Assignment

No stipulation.

9.16.3 Severability

No stipulation.

9.16.4 Enforcement (attorneys’ fees and waiver of rights)

No stipulation.

9.16.5 Force Majeure

No stipulation.

9.17 Other provisions

No stipulation.