Certification Practice Statement Policy Authority PKIoverheid Unified v5.1
Table of Contents
- 1 Introduction
- 2 Publication and electronic repository responsibilities
- 3 Identification and Authentication
- 4 Certificate Life-Cycle Operational Requirements
- 4.1 Certificate Application
- 4.2 Certificate application processing
- 4.3 Certificate issuance
- 4.4 Certificate acceptance
- 4.5 Key Pair and Certificate Usage
- 4.6 Certificate renewal
- 4.6.1 Circumstance for certificate renewal
- 4.6.2 Who may request renewal
- 4.6.3 Processing certificate renewal requests
- 4.6.4 Notification of new certificate issuance to subscriber
- 4.6.5 Conduct constituting acceptance of a renewal certificate
- 4.6.6 Publication of the renewal certificate by the CA
- 4.6.7 Notification of certificate issuance by the CA to other entities
- 4.7 Certificate re-key
- 4.7.1 Circumstance for certificate re-key
- 4.7.2 Who may request certification of a new public key
- 4.7.3 Processing certificate re-keying requests
- 4.7.4 Notification of new certificate issuance to subscriber
- 4.7.5 Conduct constituting acceptance of a re-keyed certificate
- 4.7.6 Publication of the re-keyed certificate by the CA
- 4.7.7 Notification of certificate issuance by the CA to other entities
- 4.8 Certificate modification
- 4.8.1 Circumstance for certificate modification
- 4.8.2 Who may request certificate modification
- 4.8.3 Processing certificate modification requests
- 4.8.4 Notification of new certificate issuance to subscriber
- 4.8.5 Conduct constituting acceptance of modified certificate
- 4.8.6 Publication of the modified certificate by the CA
- 4.8.7 Notification of certificate issuance by the CA to other entities
- 4.9 Certificate revocation and suspension
- 4.9.1 Circumstances for revocation
- 4.9.2 Who can request revocation
- 4.9.3 Procedure for revocation request
- 4.9.4 Revocation request grace period
- 4.9.5 Time within which CA must process the revocation request
- 4.9.6 Revocation checking requirement for relying parties
- 4.9.7 CRL issuance frequency
- 4.9.8 Maximum latency for CRLs
- 4.9.9 On-line revocation/status checking availability
- 4.9.10 On-line revocation checking requirements
- 4.9.11 Other forms of revocation advertisements available
- 4.9.12 Special requirements related to key compromise
- 4.9.13 Circumstances for suspension
- 4.9.14 Who can request suspension
- 4.9.15 Procedure for suspension request
- 4.9.16 Limits on suspension period
- 4.10 Certificate Status Services
- 4.11 End of subscription
- 4.12 Key escrow and recovery
- 5 Facility Management, Operational, and Physical Controls
- 5.1 Physical controls
- 5.2 Procedural controls
- 5.3 Personnel Security Controls
- 5.3.1 Qualifications, experience, and clearance requirements
- 5.3.2 Background check procedures
- 5.3.3 Training requirements
- 5.3.4 Retraining frequency and requirements
- 5.3.5 Job rotation frequency and sequence
- 5.3.6 Sanctions for unauthorized actions
- 5.3.7 Independent contractor requirements
- 5.3.8 Documentation supplied to personnel
- 5.4 Audit logging procedures
- 5.5 Records archival
- 5.6 Key changeover
- 5.7 Compromise and disaster recovery
- 5.8 CA or RA termination
- 6 Technical Security Controls
- 6.1 Key pair generation and installation
- 6.2 Private Key Protection and Cryptographic Module Engineering Controls
- 6.2.1 Cryptographic module standards and controls
- 6.2.2 Private key (n out of m) multi-person control
- 6.2.3 Private key escrow
- 6.2.4 Private key backup
- 6.2.5 Private key archival
- 6.2.6 Private key transfer into or from a cryptographic module
- 6.2.7 Private key storage on cryptographic module
- 6.2.8 Method of activating private key
- 6.2.9 Method of deactivating private key
- 6.2.10 Method of destroying private key
- 6.2.11 Cryptographic Module Rating
- 6.3 Other aspects of key pair management
- 6.4 Activation data
- 6.5 Computer security controls
- 6.6 Life cycle technical controls
- 6.7 Network security controls
- 6.8 Time-stamping
- 7 Certificate and CRL, and OCSP profiles
- 7.1 Certificate profile
- 7.1.1 Version number(s)
- 7.1.2 Certificate extensions
- 7.1.3 Algorithm object identifiers
- 7.1.4 Name forms
- 7.1.5 Name constraints
- 7.1.6 Certificate policy object identifier
- 7.1.7 Usage of Policy Constraints extension
- 7.1.8 Policy qualifiers syntax and semantics
- 7.1.9 Processing semantics for the critical Certificate Policies extension
- 7.2 CRL profile
- 7.3 OCSP profile
- 7.1 Certificate profile
- 8 Compliance Audit and Other Assessment
- 9 Other Business and Legal Matters
- 9.1 Fees
- 9.2 Financial responsibility
- 9.3 Confidentiality of business information
- 9.4 Privacy of personal information
- 9.4.1 Privacy plan
- 9.4.2 Information treated as private
- 9.4.3 Information not deemed private
- 9.4.4 Responsibility to protect private information
- 9.4.5 Notice and consent to use private information
- 9.4.6 Disclosure pursuant to judicial or administrative process
- 9.4.7 Other information disclosure circumstances
- 9.5 Intellectual property rights
- 9.6 Representations and warranties
- 9.7 Disclaimers of warranties
- 9.8 Limitations of Liability
- 9.9 Indemnities
- 9.10 Term and termination
- 9.11 Individual notices and communications with participants
- 9.12 Amendments
- 9.13 Dispute resolution provisions
- 9.14 Governing law
- 9.15 Compliance with Applicable Law
- 9.16 Miscellaneous provisions
- 9.17 Other provisions
1 Introduction
The Certification Practice Statement within the PKI for the government (hereinafter referred to as CPS) provides TSPs, subscribers and relying parties with information regarding the procedures and measures taken in respect of the PA’s services with regard to certificates issued by the following “Staat der Nederlanden” root certificates:
Root Certificate subject:commonName |
SHA256 Fingerprint |
---|---|
Staat der Nederlanden Root CA - G3 | 3C4FB0B9 5AB8B300 32F432B8 6F535FE1 72C185D0 FD398658 37CF3618 7FA6F428 |
Staat der Nederlanden EV Root CA | 4D249141 4CFE9567 46EC4CEF A6CF6F72 E28A1329 432F9D8A 907AC4CB 5DADC15A |
Staat der Nederlanden Private Root CA - G1 | 0257CE27 B52408E2 4EE2C094 5640B723 C5BC66DD BDA4ADA5 8C603576 04F0E675 |
TRIAL PKIoverheid Root CA - G3 | 2EAAF678 E645DC26 EA82C016 EF396093 5659CF81 B4C44D9B 2D0FB1A1 42666C98 |
The format of this CPS is, as far as possible, in accordance with the RFC 3647 standard (in full: “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework”) of the Internet Engineering Task Force.
1.1 Overview
This CPS describes the processes, procedures and control measures for applying for, producing, issuing, managing and revoking issuing certificates, insofar as the PA is directly responsible for this. This means that this CPS only relates to PKIoverheid Level 1 (root) and Level 2 (intermediate) certificates.
This CPS also describes the processes and procedures for applying for, producing, issuing and revoking Level 3 PKIoverheid TSP issuing certificates.
For a description of the processes, procedures and control measures for applying for, producing, issuing, managing and revoking Level 4 (end user certificates), please refer to the relevant Certification Practice Statements of the PKIoverheid Trust Service Providers. These CPS’s comply with the PKIoverheid Certificate Policy, called the PKIoverheid Program of Requirements (PoR). The PKIoverheid PoR describes the minimum requirements in relation to the different trust services a TSP can provide within PKIoverheid.
The image below shows the three PKIo root certificates for production environments and their respective hierarchies.
Figure 1 Image containing overview hierarchies of all PKIoverheid roots (excluding TRIAL)
The hierarchy for PKIoverheid TRIAL certificates can be found in the following image.
Figure 2 Image containing overview hierarchy of TRIAL PKIoverheid root
1.2 Document name and identification
This document is referred to as the “CERTIFICATION PRACTICE STATEMENT (CPS) for Staat der Nederlanden Root and Intermediate certificates management and issuance by PKIoverheid”.
Currently, only an English version of this CPS is maintained published. In the event that this CPS will be translated and published in another language, care will be taken that the translation will remain faithful to the original version. In case discrepancies do appear between the English and other language versions of this document, the English version shall prevail.
Naming | CERTIFICATION PRACTICE STATEMENT (CPS) for Staat der Nederlanden Root and Intermediate certificates management and issuance by PKIoverheid |
Link | https://cps.pkioverheid.nl |
OID | N/A |
Public information about the PA or PKIoverheid is available at https://www.logius.nl/pkioverheid.
1.2.1 Revisions
This section shows the revisions of both the current unified CPS, and the revisions of the separate CPSs before the decision was made to unify them in one document. Thus, this section contains the following revision tables:
- Revisions for the PKIo unified CPS (CURRENT)
- Revisions for the PKIo G2 and G3 CPS (DEPRECATED)
- Revisions for the PKIo EV CPS (DEPRECATED)
- Revisions for the PKIo Private CPS (DEPRECATED)
- Revisions for the PKIo TRIAL CPS (DEPRECATED)
Revisions for the PKIo unified CPS (CURRENT)
Version | Date of approval | Date Entry into force | Status | Author | Manager | Description |
---|---|---|---|---|---|---|
5.0 | 23-09-2022 | 17-10-2022 | Adopted by the Director of Logius | Policy Authority | A.A. de Ruiter |
|
5.1 | 12-10-2023 | 16-10-2023 | Adopted by Policy Authority | Policy Authority | A.A. de Ruiter |
|
Revisions for the PKIo G2, and G3 CPS (DEPRECATED)
Version | Date of approval | Date Entry into force | Status | Author | Manager | Description |
---|---|---|---|---|---|---|
3.4 | 24-06-2011 | 01-07-2011 | Adopted by the Director of Logius | Policy Authority | H. Verweij |
|
3.5 | 29-06-2012 | 01-07-2012 | Adopted by the Director of Logius | Policy Authority | H. Verweij |
|
3.6 | 04-02-2013 | 04-02-2013 | Adopted by the Ministry of the Interior and Kingdom Relations | Policy Authority | H. Verweij |
|
3.7 | 18-12-2013 | 18-12-2013 | Adopted by the Director of Logius | Policy Authority | M.A. Janssen |
|
3.8 | June 2014 | July 2014 | Adopted by the Director of Logius | Policy Authority | M.A. Janssen |
|
3.9 | February 2015 | February 2015 | Adopted by the Director of Logius | Policy Authority | M.A. Janssen |
|
4.0 | October 2016 | October 2016 | Adopted by the Director of Logius | Policy Authority | M.A. Janssen |
|
4.1 | December 2017 | December 2017 | Adopted by the PA PKIoverheid | Policy Authority | M.A. Janssen |
|
4.2 | November 2018 | November 2018 | Adopted by the Director of Logius | Policy Authority | M.A. Janssen |
|
4.3 | December 2019 | December 2019 | Adopted by the Director of Logius | Policy Authority | J.G. van ’t Hof |
|
4.4 | December 2020 | December 2020 | Adopted by the Director of Logius | Policy Authority | A.J.M. Hielkema |
|
4.5 | April 2021 | April 2021 | Adopted by the Director of Logius | Policy Authority | R.P. Leyting |
|
4.6 | April 2022 | April 2022 | Adopted by the Director of Logius | Policy Authority | A.A. de Ruiter |
|
Revisions for the PKIo EV CPS (DEPRECATED)
Version | Date of approval | Date Entry into force | Status | Author | Manager | Description |
---|---|---|---|---|---|---|
1.0 | 18-01-2011 | 25-01-2011 | Adopted by the Director of Logius | Policy Authority | H. Verweij |
|
1.1 | 24-06-2011 | 01-07-2011 | Adopted by the Director of Logius | Policy Authority | H. Verweij |
|
1.2 | 04-02-2013 | 04-02-2013 | Adopted by the Ministry of the Interior and Kingdom Relations | Policy Authority | H. Verweij |
|
1.3 | June 2014 | July 2014 | Adopted by the Director of Logius | Policy Authority | M.A. Janssen |
|
1.4 | February 2015 | February 2015 | Adopted by the Director of Logius | Policy Authority | M.A. Janssen |
|
1.5 | October 2016 | October 2016 | Adopted by the Director of Logius | Policy Authority | M.A. Janssen |
|
1.6 | December 2017 | December 2017 | Adopted by the PA PKIoverheid | Policy Authority | M.A. Janssen |
|
1.7 | December 2018 | December 2018 | Adopted by the Director of Logius | Policy Authority | M.A. Janssen |
|
1.8 | December 2019 | December 2019 | Adopted by the Director of Logius | Policy Authority | J.G. van ’t Hof |
|
2.0 | July 2020 | July 2020 | Adopted by the Director of Logius | Policy Authority | J.G. van ’t Hof |
|
2.1 | April 2021 | April 2021 | Adopted by the Director of Logius | Policy Authority | R.P. Leyting |
|
2.2 | April 2022 | April 2022 | Adopted by the Director of Logius | Policy Authority | A.A. de Ruiter |
|
Revisions for the PKIo Private CPS (DEPRECATED)
Version | Date of approval | Date Entry into force | Status | Author | Manager | Description |
---|---|---|---|---|---|---|
1.0 | June 2014 | July 2014 | Adopted by the Director of Logius | Policy Authority | M.A. Janssen |
|
1.1 | February 2015 | February 2015 | Adopted by the Director of Logius | Policy Authority | M.A. Janssen |
|
1.2 | October 2016 | October 2016 | Adopted by the Director of Logius | Policy Authority | M.A. Janssen |
|
1.3 | December 2017 | December 2017 | Adopted by the PA PKIoverheid | Policy Authority | M.A. Janssen |
|
1.4 | December 2018 | December 2018 | Adopted by the Director of Logius | Policy Authority | M.A. Janssen |
|
1.5 | December 2019 | December 2019 | Adopted by the PA PKIoverheid | Policy Authority | J.G. van ’t Hof |
|
1.6 | December 2020 | December 2020 | Adopted by the PA PKIoverheid | Policy Authority | R.P. Leyting |
|
Revisions for the PKIo TRIAL CPS (DEPRECATED)
Version | Date of approval | Date Entry into force | Status | Author | Manager | Description |
---|---|---|---|---|---|---|
1.0 | 28-04-2009 | 28-04-2009 | Adopted by the Director of Logius | Policy Authority | T. Behre |
|
1.1 | 17-11-2009 | 17-11-2009 | Adopted by the Director of Logius | Policy Authority | H. Verweij |
|
1.2 | 11-01-2010 | 11-01-2010 | Adopted by the Ministry of the Interior and Kingdom Relations | Policy Authority | H. Verweij |
|
2.0 | 10-02-2012 | 10-02-2012 | Adopted by the Director of Logius | Policy Authority | H. Verweij |
|
3.0 | October 2016 | October 2016 | Adopted by the Director of Logius | Policy Authority | M.A. Janssen |
|
1.2.2 Relevant Dates
See the “Date of entry into force” column in Section 1.2.1 of this CPS. Specific dates in CPS sections always prevail over a general date.
1.3 PKI Participants
The Ministry of the Interior and Kingdom Relations (BZK) is responsible for PKIoverheid. The Ministry of the Interior and Kingdom Relations makes decisions regarding the layout of the infrastructure and the participation of TSPs with the PKIoverheid framework. The director of Logius represents the Ministry of the Interior and Kingdom Relations in this matter.
The Policy Authority advises the director of Logius and is responsible for managing the level 1 and level 2 CAs of the PKI for the government and supervising and monitoring the work of TSPs that issue certificates to end-users.
One or more TSPs operate in each domain of the PKI for the government. Within a domain of the PKI for the government, a TSP will issue certificates to the certificate end-users.
1.3.1 Certification authorities
The PKIo Policy Authority, as well as TSPs issuing end user certificates, can be regarded a certification Authorities. Both are described separately in underlying sections.
1.3.1.1 PKIo Policy Authority
The Policy Authority (PA) of the PKI for the Dutch government (PA PKIoverheid) supports the Dutch Ministry of the Interior and Kingdom Relations (BZK) in managing PKIoverheid.
The responsibilities of the PA PKIoverheid are:
- further developing and maintaining the framework of underlying standards for the PKI for the government, the Programme of Requirements (PoR),
- the PKIoverheid Certificate Policy (CP); assisting Trust Service Providers (TSPs) in the process of admittance to PKI for the government and preparing the administrative handling,
- supervising and monitoring the activities of TSPs issuing certificates for the government under the root of the PKI for the government.
The Policy Authority (PA) is responsible for managing the top tiers (level 1 and 2) of the hierarchy. PKIoverheid is structured so that external organizations, the Trust Service Providers (TSPs), can be admitted to PKIoverheid under certain conditions. Participating TSPs are responsible for the services for subscribers within the PKIoverheid framework. The PA supervises the TSPs, and as such ensures the trustworthiness of PKIoverheid as a whole.
In practice, this entails:
- management of the PKIoverheid CP (Programme of Requirements);
- management of Object Identifiers (OIDs), the unique numbers for TSPs and their CPSs;
- creation and management of key pair and the corresponding root certificate;
- revoking the root certificate and ad-hoc publication of the CRL;
- creation and management of key pairs and the corresponding intermediate (level 2) certificates;
- revocation of intermediate certificates and ad-hoc publication of the corresponding CRL;
- Preparing and supervising admission of TSPs to PKIoverheid (including creation, issuance and management of TSP CA certificates);
- supervision of PKIoverheid TSPs;
- preparation and implementation (including creation, issuance and publication) of new TSP issuing certificates;
- preparation and implementation of revocation of TSP issuing certificates;
- periodic and ad-hoc publication of the TSP (level 3) certificates;
- registration and assessment of audit (ETSI/Webtrust) reports;
- registration and assessment of (external) threats to PKIoverheid.
KPN B.V. is responsible for the technical management of all PKIoverheid root and intermediate certificates, including maintaining the corresponding Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCPS) responders.
The PKIoverheid Policy Authority is part of Logius (http://www.logius.nl), the digital government service of the Ministry of the Interior and Kingdom Relations.
1.3.1.2 Trust Service Providers
An up-to-date list of all PKIo Trust Service Providers, and the type(s) of certificates they are capable of issuing, can be found on: https://cert.pkioverheid.nl
1.3.2 Registration authorities
RA responsibility for level 1, level 2 and level 3 CAs has been delegated by BZK to the PA PKIoverheid. As such, the PA PKIoverheid is responsible for identification and registration of the TSPs and their associated key personell. For more information, see section 3.
1.3.3 Subscribers
Due to the fact that the PA PKIoverheid only issues CA certificates to TSPs (which will be referred to as “TSP Issuing Certificates” in the rest of this document), they act as “subscribers” for the purpose of this document. All requirements and responsibilities of the TSPs are detailled in the CP (“Programme of Requirements”) PKIoverheid. To legally enforce the CP, a separate contract is drafted and signed by the parties involved. For details regarding agreement between end-users and TSPs, please refer to the relevant CPS of the TSP in question.
1.3.4 Relying parties
The relying party is the recipient of a certificate issued within PKIoverheid and acts on the basis of trust in the certificate. The relying party is obliged to check the validity of the full chain of certificates through to the source (root certificate) on which trust is placed.
1.3.5 Other participants
Other participants in PKIoverheid are:
- The Ministry of the Interior and Kingdom Relations (Dutch: Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, or BZK): This ministry is responsible for PKIoverheid. It makes decisions regarding the layout of the infrastructure and the participation of TSPs with the PKIoverheid framework. The director of Logius represents the Ministry of the Interior and Kingdom Relations in this matter.
- Radiocommunications Agency Netherlands (Dutch: Agentschap Telecom, or AT): The Radiocommunications Agency Netherlands is the Dutch National Accreditation body for eIDAS Qualified TSP’s, as wel as a regulatory body for the supervision of TSPs operating in the Netherlands.
- National Cyber Security Centre (Dutch: Nationaal Cyber Security Centrum, or NCSC): The NCSC advises on certificate usage within the Dutch government.
1.4 Certificate Usage
See sub-sections.
1.4.1 Permitted Certificate Usage
Within the PKI for the government, different types of certificates are defined at four levels, which are:
- Root certificate;
- Domain certificate;
- TSP certificate;
- End user certificate.
The root certificate, the domain certificates and the TSP certificates can only be used to verify the issuer’s signature and are issued by the Policy Authority. These certificates may not be used for other purposes. The end user certificate is issued by the TSPs. End user certificates can be used in different domains and with differrent purposes:
- Domain Server 2020:
- server authentication;
- Domain Organization Person:
- authenticity;
- non-repudiation;
- confidentiality;
- Domain Organization Services:
- authenticity;
- non-repudiation;
- confidentiality;
- Domain Citizen:
- authenticity;
- non-repudiation;
- confidentiality;
- Domain Autonomous Devices:
- authenticity;
- confidentiality;
- combination;
- Domain Private Services:
- authenticity;
- confidentiality;
- server authentication;
- Domain Private Person:
- authenticity;
- non-repudiation;
- confidentiality.
1.4.2 Prohibited Certificate Usage
Certificates issued under this CPS may not be used other than as described in section 1.4.1.
1.5 Policy Administration
In addition to this CPS there are two additional PKIo documents which need to be publicly disclosed and require an effective administrative process:
- the Program of Requirements for PKIoverheid TSPs, and
- the Registration of PKIoverheid OIDs.
Although not strictly policy documents, the administration of these documents will also be described in this section because of their equal importance.
1.5.1 The organization responsible for managing policies
The Ministry of the Interior and Kingdom Relations is responsible for all PKIoverheid policy documents. The Ministry has delegated this task to Logius.
1.5.2 Contact information
In case of any questions or issues with PKIoverheid end-user certificates (level 4), the TSP which issued the end-user certificate should be contacted (contact details are found in their respective CPS).
In case of any questions or issues relating to the TSP CA (level 3), Domain CA (level 2), Root CA (level 1) and/or their associated OCSP responders and/or CRLs the reporting party should contact Logius through the contact information below. Revocation procedures are also described in section 4.9.1. and 4.9.3. of this CPS.
Policy Authority PKIoverheid
Wilhelmina van Pruisenweg 52
P.O. Box 96810
2509 JE THE HAGUE
NETHERLANDS
Website: <https://www.logius.nl/pkioverheid>
General telephone number: +31(0)708896360
Email: <servicecentrum@logius.nl>
1.5.3 The person determining policy documents suitability for Certificate Policies
The PA PKIoverheid does not have its own general Certificate Policy. For publicly trusted roots the CA/B Forum Baseline Requirements document applies. The PA determines if changes in the PKIoverheid policies are needed after updates to the CA/B Forum Baseline Requirements.
1.5.4 Policy approval procedures
The policy approval procedure differs per policy document. The PA of PKIoverheid is entitled to change or to add to this CPS. However, the management of Logius is responsible for both acknowledging the procedure described in paragraph 9.12 is followed accurately, and the ultimate approval of this CPS. Only in case of editorial changes the head of the PA PKIoverheid can approve a new version of the CPS for publication.
Changes to the Registration of PKIoverheid OIDs can be approved by the PA PKIoverheid.
For the Programme of Requirements the procedure outlined in section 9.12 is followed. Initial approval of the PoR is given by the PA PKIoverheid. Final approval is needed from the Ministry of the Interior and Kingdom Relations before a new version can be formalized and published.
1.6 Definitions and abbreviations
See sub-sections.
1.6.1 Definitions
Definitions used in this CPS and the Programme of Requirements are listed in part 4 of the PoR, which can be found at https://www.logius.nl/english/pkioverheid.
1.6.2 Acronyms
Acronyms used in this CPS and the Programme of Requirements are listed in part 4 of the PoR, which can be found at https://www.logius.nl/english/pkioverheid.
2 Publication and electronic repository responsibilities
See sub-sections.
2.1 Electronic repository
PKIoverheid information is published in the following locations:
- This CPS is published on the PKIoverheid website: https://cps.pkioverheid.nl
- The PKIoverheid Programme of Requirements and OID Registration are published on the PKIoverheid product page on the Logius website: https://www.logius.nl/english/pkioverheid
- TSP CPSs, issued certificates and Certificate Revocation Lists are published on the TSP websites.
2.2 Publication certificate information
PKIoverheid certificate information is published in the following locations:
- Official notifications on both PKIoverheid Public and Private root certificates are published in the Official Gazette (Staatscourant).
- The PKIoverheid root, intermediate, and TSP issuing certificates are published on the PKIoverheid website: https://cert.pkioverheid.nl.
- The PKIoverheid Certificate Revocation Lists for its intermediate certificates and the TSP issuing certificates are published on the PKIoverheid website: https://crl.pkioverheid.nl.
Test websites for Application Software Suppliers (per BRG 2.2) are available on the following URLs:
- https://roottest-ev.pkioverheid.nl
- https://roottest-ev-expired.pkioverheid.nl
- https://roottest-ev-revoked.pkioverheid.nl
2.3 Time or frequency of publication
PKIoverheid information is published with the following frequency:
- A new version of this CPS is published at least once a year.
- A new version of the PKIoverheid Programme of Requirements normally is published once or twice a year.
- New versions of the OID Registration are published when needed.
- The PKIoverheid product page on the Logius website is updated when needed.
- TSP CPSs, issued certificates and Certificate Revocation Lists publication frequencies can vary per TSP and are described in their own CPSs
- The CRL for PKIoverheid intermediate certificates is (re)published annually, or after revocation of an intermediate certificate, whichever is earlier.
- OCSP Responders update their information at least every twelve months and always within 24 hours after revoking an Intermediate or TSP Issuing Certificate.
2.4 Access controls to publication
Published PKIoverheid information is public in nature and freely accessible.
Write access to PKIoverheid information is limited to authorized personnel only:
- only employees of the Logius Communication team have write access to the public repository of the PKIoverheid Programme of Requirements and OID Registration documents;
- only the Logius PKIoverheid team has write access to the development environment for the PKIoverheid Programme of Requirements, OID Registration, and CPS documents;
- only the Operations team has write access to the public repository of the CPS, certificate, and CRLs;
- only the Operations team has write access to the OCSP Responder environments.
3 Identification and Authentication
See sub-sections.
3.1 Naming
See sub-sections.
3.1.1 Types of names
All PKIoverheid Root, Intermediate, and TSP certificates contain a sequence of three RelativeDistinguishedName
fields in both issuer
and subject
fields, each containing one of the following attribute types:
countryName
organizationName
commonName
Only the subject
field in TSP certificates under both the PKIoverheid G3 and Private roots contain an additional RelativeDistinguishedName
field with attribute type:
organizationIdentifier
For name types in PKIoverheid end user certificates, please refer to the relevant Certification Practice Statements of the PKIoverheid TSPs.
All name types in PKIoverheid certificates adhere to the ITU-T X.520 attribute naming scheme.
3.1.2 Need for names to be meaningful
Names in subject and issuer fields need to be meaningful and need to uniquely identify subject and issuer respectively.
3.1.3 Pseudonyms
Within PKIoverheid no certificates are issued with pseudonimized or anonimized data in name attributes.
3.1.4 Rules for interpreting various name forms
The attribute types in the RelativeDistinguishedName
fields in both the issuer
and subject
fields of PKIoverheid Root, Intermediate, and TSP certificates must be interpreted in the following way:
countryName
: Contains the two-letter ISO 3166-1 country code associated with the country of incorporation of the issuer- or subject-organization, as can be found in a Chamber of Commerce’s Trade Register or a law, deed of incorporation or a general governmental decree.organizationName
: Contains the exact organization name of the issuer or subject, as can be found in a Chamber of Commerce’s Trade Register or a law, deed of incorporation or a general governmental decree.commonName
: Contains the common name of a certificate, conforming to PKIoverheid naming standards, but usually incorporating the organisation name of the subject, a meaningful certificate identifier, and a generation identifier.organizationIdentifier
: Contains the respective organization’s Chamber of Commerce number.
3.1.5 Uniqueness of names
All PKIoverheid certificates contain a subject and issuer field which can be used to uniquely identify the subscriber as subject or issuer respectively. However, in rare circumstances the subject:commonName
field does not always uniquely identify the certificate itself.
3.1.6 Recognition, authentication and role of trademarks
All organisationName
attributes in PKIoverheid Root, Intermediate and TSP certificates are exact copies from either the Dutch Trade Register of the Chamber of Commerce, or from the Staatsalmanak. Both are reliable data sources obliged by law to perform strong recognition, authentication and trademark checks. Correctness of this information is therefore assumed by the PKIoverheid PA.
3.2 Initial identity validation
See sub-sections.
3.2.1 Initial Registration Process
For the requirements laid down in relation to the initial registration process, see the PKIoverheid Programme of Requirements, part 2.
3.2.2 Authentication of organizational identity
Based on the application form and the evidence that is supplied, the PA verifies, - That the TSP is an existing organization listed in the National Trade Register (NHR) or an organizational entity that forms part of an existing organization listed in the NHR. If a government organization is not listed in the NHR, the Staatsalmanak is consulted; - That the name of the organization and country name registered by the TSP to be incorporated in the certificate are correct and complete and that the applicant is authorized to represent the organization; - The presence of the relevant registration information of the prospective TSP, with the corresponding evidence (excerpt from the Chamber of Commerce, etc.). The excerpt must be original and must not be older than 13 months.
Note: If the participating party has existed for less than three years and does not appear in the latest version of the registration sources listed above, the identity and validity of the prospective TSP may be established using a parent company or ministry that is registered in the NHR or the Staatsalmanak.
3.2.3 Authentication of individual identity
Upon initial admittance to the PKIoverheid framework, the PA verifies the listed personal data of the authorized representative of the TSP using an identity document issued under art. 1 of the Compulsory Identification Act, limited to the following documents:
- a valid travel document referred to in the Passport Act (Paspoortwet);
- a valid driving license issued on the basis of the Road Traffic Act (Wegenverkeerswet), under article 107 of the Road Traffic Act (Wegenverkeerswet) 1994.
3.2.4 Non-verified subscriber information
No stipulation.
3.2.5 Validation of authority
The PKIoverheid PA maintains an authorization list with contacts per PKIoverheid TSP. This authorization list recognizes the following general roles:
- Operational contact;
- Authorized signatory.
A TSP has the possibility to split up their operational contact in two or moredifferent specialized roles:
- General contact, and
- Incident contact, and/or
- Emergency contact, and/or
- RFC discussion contact, and/or
- RFC approval contact, and/or
- Contact for penetration testing.
Initial contacts per TSP have to be approved by the authorized signatory and communicated through a verified method of communication. Consecutive changes may be approved by people within the same role, again through a verified method of communication.
An authorized signatory has to be listed as Director in the National Trade Register (NHR). When a TSP is a government agency without an entry in the NHR, the authorized signatory has to be at least equal to the role of Director in the Staatsalmanak.
Note: Per TSP only authorized signatories can request new issuing certificates or revocation of issuing certificates.
3.2.6 Criteria for interoperation
Cross-signing of certificates is not allowed within PKIoverheid.
3.3 Identification and authentication for Re-Key Requests
See sub-sections.
3.3.1 Identification and authentication for routine re-key
Only TSP employees with the role of signed signatory in the PKIoverheid authorization list are authorized to commit re-key requests for the TSP in question. For PKIoverheid root or intermediate certificates this can only be done by the PKIoverheid Policy Authority.
Re-key requests by TSPs always need to be signed by the TSP’s signed signatory as listed in the PKIoverheid authorization list. For PKIoverheid root or intermediate certificates the requests have to be signed with a qualified signature by the PKIoverheid Policy Authority.
3.3.2 Identification and authentication for re-key after revocation
The same procedure applies as for routine re-key. Therefore see Section 3.3.1.
3.4 Identification and authentication for Revocation Requests
Only TSP employees with the role of signed signatory in the PKIoverheid authorization list are authorized to perform Revocation requests for the TSP in question. For PKIoverheid intermediate certificates this can only be done by the PKIoverheid Policy Authority.
Revocation requests by TSPs always need to be signed by the TSP’s signed signatory as listed in the PKIoverheid authorization list. For PKIoverheid intermediate certificates the requests have to be signed with a qualified signature by the PKIoverheid Policy Authority.
4 Certificate Life-Cycle Operational Requirements
See sub-sections.
4.1 Certificate Application
See sub-sections.
4.1.1 Who can submit a certificate application
PKIoverheid TSPs can submit applications for TSP issuing certificates; the PKIoverheid PA can submit applications for PKIoverheid root or intermediate certificates. Only TSP employees with the role of signed signatory in the PKIoverheid authorization list can submit certificate applications.
4.1.2 Enrollment process and responsibilities
Certificate proposals for new TSP issuing certificates need to be electronically submitted to the PKIoverheid PA using a template provided by the PKIoverheid team, and signed by TSP signed signatory. A CSR had to be provided with the template.
Certificate proposals for new root or intermediate certificates can be submitted by the PKIoverheid PA itself, at the instruction of the Ministry of the Interior and Kingdom Relations.
4.2 Certificate application processing
See sub-sections.
4.2.1 Performing Identification and Authentication Functions
Signatures of submitted certificate proposals are verified, and its signers are checked against the list of authorized signed signatories.
Submitted subject data fields are checked against qualified data sources. Validation will be performed no longer than 2 months prior to issuing of the certificate.
4.2.2 Approval or Rejection of Certificate Applications
Certificate applications which do not pass the identification and authentication checks listed in Section 4.2.1. will be rejected.
For certificate application which pass the identification and authentication checks first a naming document is created for a trial key ceremony producing a test certificate.
In case of a test Root certificate or Intermediate certificate the PKIoverheid team itself performs tests to verify the contents of the certificate. In case of a TSP Issuing certificate both the TSP and the PKIoverheid team verify its contents. If the content of the certificate is agreed upon to be correct, a production naming document will be created.
4.2.3 Time to Process Certificate Applications
No stipulation.
4.3 Certificate issuance
See sub-sections.
4.3.1 CA actions during certificate issuance
PKIoverheid root, intermediate, and TSP issuing certificates are created during special creation ceremonies. For every key ceremony, a detailed script is produced which lists all tasks to be carried out. The main purpose of this script is to prevent any input errors during the ceremony. All creation ceremonies takes place in the presence of independent witnesses, including an internal or external auditor, except for issuances under the PKIoverheid TRIAL root. The identity of all persons present is verified using the valid documents referred to under article 1 of the Compulsory Identification Act (“Wet op de identificatieplicht” in Dutch) with the exception of Key Management team members who are allowed to use the company identity card for this.
All ceremonies follow these general steps:
- building the computer system for certificate issuance;
- installing and configuring the PKI software;
- 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;
- generating the key pairs (only applicable to root and intermediate certificates);
- generating certificates for each key pair;
- dismantling the computer system, and
- securing the computer system and the critical components.
Public keys for TSP issuing certificates are provided by the TSP itself through a CSR, communicated in a trustworthy manner.
4.3.2 Notification to subscriber by the CA of issuance of Certificate
TSP issuing certificates are sent to the TSP by the PKIoverheid PA in a trustworthy manner. This communication is regarded as an official notification.
In case of a root or intermediate certificate, no additional notification is needed.
4.4 Certificate acceptance
See sub-sections.
4.4.1 Conduct constituting certificate acceptance
In case of Root certificates and Intermediate certificates, if no issues are found within two weeks acceptance of is formalized by a letter signed by the PKIoverheid PA sent to the PKIoverheid Key Management team.
In case of TSP Issuing certificates, delivery of the certificate to the TSP is accompanied by an acceptance letter which the TSP has to sign and return to the PKIoverheid PA within two weeks when no issues are found. The PKIoverheid PA will forward this letter to the PKIoverheid Key Management team.
4.4.2 Publication of the certificate by the CA
All issued PKIoverheid root, intermediate, and TSP issuing certificates are published on https://cert.pkioverheid.nl/. In addition to this, the most relevant attributes of all PKIoverheid root certificates (excluding TRIAL root certificates) are also published in the Official Gazette (Staatscourant).
4.4.3 Notification of certificate issuance by the CA to other Entities
All PKIoverheid TSPs will be notified by E-mail by the PKIoverheid PA after the creation of a new PKIoverheid Root or Intermediate certificate.
4.5 Key Pair and Certificate Usage
See sub-sections.
4.5.1 Subscriber private key and certificate usage
PKIoverheid root, intermediate, and TSP issuing certificates are used for verifying the issuer’s signature on a subject’s certificate.
Private keys corresponding to the public keys in PKIoverheid root, intermediate, and TSP issuing certificates, are used for signing:
- certificates issued by those certificates,
- OCSP-signing certificates (only if an OCSP responder is used for those certificates), and
- CRL responses on certificates issued by those certificates.
4.5.2 Relying party public key and certificate usage
No stipulation.
4.6 Certificate renewal
See sub-sections.
4.6.1 Circumstance for certificate renewal
Normal certificate renewal happens when a certificate’s validity period is close to expiring. Only when information which is included in a certificate, changes or is out of date, this is reason for an early renewal. Examples are a change in the name of a TSP as included in the certificate, or if the strength of the key generation algorithm is outdated and deemed insufficient thus needing a new stronger key.
The PKIoverheid PA aims to introduce a new generation of each PKIoverheid root certificate once every five years. The previous generation will exist alongside the new one until it expires. This method ensures enough time for TSPs and en-users to transition to the new generation.
4.6.2 Who may request renewal
For certificate renewal the same rules apply as for certificate application (see Section 4.1.1.
4.6.3 Processing certificate renewal requests
For the processing of certificate renewals the same rules apply as for processing of certificate applications (see Section 4.2).
4.6.4 Notification of new certificate issuance to subscriber
For the notification of renewed certificate issuances the same process applies as for notification of certificate issuances after application (see Section 4.3.2.
4.6.5 Conduct constituting acceptance of a renewal certificate
For the acceptance of renewed certificate issuances the same rules apply as for the acceptance of certificate issuances after application (see Section 4.4.1).
4.6.6 Publication of the renewal certificate by the CA
For the publication of renewed certificate issuances the same rules apply as for the acceptance of certificate issuances after application (see Section 4.4.2).
4.6.7 Notification of certificate issuance by the CA to other entities
For the notification to other entities of new certificate issuances the same rules apply as for notification to other entities of certificate issuances after application (see Section 4.4.3).
4.7 Certificate re-key
It is PKIoverheid policy to not support changing the existing public key in a certificate (also known as certificate re-key). Only in rare cases deviation from this policy will be considered by the PKIoverheid PA when substantial reasons exist to do so.
4.7.1 Circumstance for certificate re-key
Not applicable.
4.7.2 Who may request certification of a new public key
Not applicable.
4.7.3 Processing certificate re-keying requests
Not applicable.
4.7.4 Notification of new certificate issuance to subscriber
Not applicable.
4.7.5 Conduct constituting acceptance of a re-keyed certificate
Not applicable.
4.7.6 Publication of the re-keyed certificate by the CA
Not applicable.
4.7.7 Notification of certificate issuance by the CA to other entities
Not applicable.
4.8 Certificate modification
Certificate Modification is not supported within the central hierarchy of PKIoverheid. When modifications need to take place, this has to be done through the certificate renewal process (see Section 4.6).
4.8.1 Circumstance for certificate modification
Not applicable.
4.8.2 Who may request certificate modification
Not applicable.
4.8.3 Processing certificate modification requests
Not applicable.
4.8.4 Notification of new certificate issuance to subscriber
Not applicable.
4.8.5 Conduct constituting acceptance of modified certificate
Not applicable.
4.8.6 Publication of the modified certificate by the CA
Not applicable.
4.8.7 Notification of certificate issuance by the CA to other entities
Not applicable.
4.9 Certificate revocation and suspension
See sub-sections.
4.9.1 Circumstances for revocation
Revocation of Intermediate, TSP Issuing, or OCSP-Signing certificates will in any case be considered if the private key belonging to the certificate is compromised or suspected to be compromised. Indicators of private key compromise may include:
- Theft or loss of device holding a private key;
- Audit findings indicating private key compromise;
- CT Log findings indicating unauthorized certificate signing;
- Incidents reported to Logius by third parties which may indicate key compromise.
All indicators are registered, analyzed, and followed up accordingly.
The PA considers compromise of an intermediate or a TSP issuing certificate’s private key to be an emergency, and will be dealt with accordingly, as described in Section 5.7 of this CPS.
Root certificates cannot be revoked, and have to be removed from trusted root stores instead. Circumstances for removal from trust stores and revocation are the same.
The following list of circumstances are all reasons for revocation. The list also shows the associated cRLReason
codes which have to be used in CRL’s or OCSP responses. - Compromised Private Key: [1] keyCompromise
- Compromised Private Key of CA: [2] cACompromise
- Changed affiliation: [3] affiliationChanged
- Certificate superseded: [4] superseded
- Cessation of operation: [5] cessationOfOperation
- Privilege withdrawn: [9] privilegeWithdrawn
These reasons for revocation are described in more detail below.
Compromised Private Key
The revocation reason keyCompromise [1]
may only be used only in combination with the revocation of PKIoverheid OCSP-Signing certificates when one or more of the following occurs:
- the PKIoverheid PA obtains verifiable evidence that the private key corresponding to the public key in a certificate suffered a key compromise;
- the PKIoverheid PA is made aware of a demonstrated or proven method that exposes the private key corresponding to the public key in a certificate to compromise;
- there is clear evidence that the specific method used to generate the private key corresponding to the public key in a certificate was flawed; or
- the PKIoverheid PA is made aware of a demonstrated or proven method that can easily compute the private key based corresponding to the public key in a certificate (such as a Debian weak key, see https://nvd.nist.gov/vuln/detail/cve-2008-0166).
When the PA obtains verifiable evidence of private key compromise for a certificate whose CRL entry has a reasonCode
extension with a non-keyCompromise
reason, the PA will update the CRL entry to enter keyCompromise
as the revocation reason in the reasonCode
extension. Additionally, the PKIoverheid PA will update the revocation date in a CRL entry when it is determined that the private key of the certificate was compromised prior to the revocation date that is indicated in the CRL entry for that certificate.
Otherwise, the keyCompromise
revocation reason will not be used.
Compromised Private Key of CA
The revocation reason caCompromise [2]
is used in combination with PKIoverheid Intermediate certificates or TSP Issuing certificates when one or more of the following occurs:
- the PKIoverheid PA obtains verifiable evidence that the private key corresponding to the public key in a certificate suffered a key compromise;
- the PKIoverheid PA is made aware of a demonstrated or proven method that exposes the private key corresponding to the public key in a certificate to compromise;
- there is clear evidence that the specific method used to generate the private key corresponding to the public key in a certificate was flawed;
- the PKIoverheid PA is made aware of a demonstrated or proven method that can easily compute the private key based corresponding to the public key in a certificate (such as a Debian weak key, see https://nvd.nist.gov/vuln/detail/cve-2008-0166); or
- after the request by a TSP for this reason the PKIoverheid PA revokes the TSP’s Issuing certificate.
When the PA obtains verifiable evidence of private key compromise for a certificate whose CRL entry has a reasonCode
extension with a non-caCompromise
reason, the PA will update the CRL entry to enter caCompromise
as the revocation reason in the reasonCode
extension. Additionally, the PKIoverheid PA will update the revocation date in a CRL entry when it is determined that the private key of the certificate was compromised prior to the revocation date that is indicated in the CRL entry for that certificate.
Otherwise, the keyCompromise revocation reason will not be used.
Changed affiliation
The revocation reason affiliationChanged [3]
is used in combination with PKIoverheid TSP Issuing certificates to indicate that the TSP’s name or other subject identity information in the certificate has changed, but there is no cause to suspect that the certificate’s private key has been compromised. Unless the caCompromise
revocation reason is being used, the revocation reason affiliationChanged
is used when:
- the TSP has requested that their certificate be revoked for this reason; or
- the PKIoverheid PA has replaced the certificate due to changes in the certificate’s subject information and the PA has not replaced the certificate for the other reasons:
keyCompromise
,superseded
,cessationOfOperation
, orprivilegeWithdrawn
.
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
orprivilegeWithdrawn
.
Otherwise, the superseded
revocation reason will not be used.
Cessation of operation
Unless the caCompromise
revocation reason is being used, the revocation reason cessationOfOperation [5]
is used in combination with TSP Issuing certificates when:
- the subscribing TSP has requested that their certificate be revoked for this reason; or
- the PKIoverheid PA has received verifiable evidence that the subscribing TSP has stopped its Trust Services or has stopped doing business in its entirety.
Otherwise, the cessationOfOperation
revocation reason will not be used.
Privilege withdrawn
Unless the caCompromise
revocation reason is being used, the revocation reason privilegeWithdrawn [9]
is used in combination with TSP Issuing certificates when:
- the PKIoverheid PA obtains evidence that the certificate was misused;
- the PKIoverheid PA is made aware that the TSP has violated one or more of its material obligations under the PKIoverheid Program of Requirements or Contract;
- the PKIoverheid PA is made aware of a material change in the information contained in the certificate;
- the PKIoverheid PA determines or is made aware that any of the information appearing in the certificate is inaccurate; or
- the PKIoverheid PA is made aware that the original certificate request was not authorized and that the TSP does not retroactively grant authorization.
Otherwise, the privilegeWithdrawn
revocation reason will not be used.
4.9.2 Who can request revocation
The PKIoverheid PA can request PKIoverheid Key Management to revoke intermediate and/or TSP issuing certificates.
Additionally, TSP signed signatories can request revocation of their issuing certificates. They have to send this request to the PKIoverheid PA who passes it on to PKIoverheid Key Management.
Root certificates cannot be revoked, and have to be removed from trusted root stores instead. The Ministry of the Interior and Kingdom Relations has to approve the removal of PKIoverheid root certificates from trust stores.
4.9.3 Procedure for revocation request
Prior to distrust of a root certificate, or revocation of an intermediate or TSP issuing certificate, a careful assessment process is followed. The emergency team will perform this assessment and will initiate any activities that may ensue from this.
Prior to distrusts of revocations, all PKIoverheid TSPs will be informed.
4.9.4 Revocation request grace period
No stipulation.
4.9.5 Time within which CA must process the revocation request
PKIoverheid Key Management will process a revocation within one working day after reception of a request.
4.9.6 Revocation checking requirement for relying parties
No stipulation.
4.9.7 CRL issuance frequency
A new CRL for intermediate and TSP issuing certificates will be issued once every 364 days, or when a revocation request has been processed, whichever comes first.
4.9.8 Maximum latency for CRLs
The revocation of a domain certificate or a TSP certificate always leads to ad-hoc publication of the relevant modified CRL. The revocation of certificates and the issue of CRLs takes place in accordance with a pre-prepared script. The new CRL will be published a maximum of 24 hours after revocation of a domain or TSP CA.
4.9.9 On-line revocation/status checking availability
CRLs for ALL PKIoverheid intermediate and TSP issuing certificates can be found at: http://crl.pkioverheid.nl.
OCSP for PKIoverheid intermediate and TSP issuing certificates can be found at:
- for “Staat der Nederlanden Domein Server CA 2020 CA” intermediate certificate: http://evrootocsp.pkioverheid.nl;
- for all underlying TSP issuing certificates: http://domserver2020ocsp.pkioverheid.nl;
- for “Staat der Nederlanden Organisatie Services CA - G3” intermediate certificate: http://rootocsp-g3.pkioverheid.nl;
- for all underlying TSP issuing certificates: http://domorganisatieservicesocsp-g3.pkioverheid.nl .
4.9.10 On-line revocation checking requirements
PKIoverheid OCSP responders support the HTTP GET method, as described in RFC 6960.
The PKIoverheid OCSP responder updates its information
- at least once every twelve months, and
- within 24 hours after revoking a subordinate certificate.
If a PKIoverheid OCSP responder receives a request for the status of a certificate serial number that is “unused”, then the responder does not respond with a “good” status.
PKIoverheid Key Management monitors its OCSP responders for requests for “unused” serial numbers as part of its security response procedures.
4.9.11 Other forms of revocation advertisements available
No other form of revocation advertisement is available.
4.9.12 Special requirements related to key compromise
See Section 4.9.1.
4.9.13 Circumstances for suspension
Suspension of certificates is not supported within PKIoverheid.
4.9.14 Who can request suspension
Suspension of certificates is not supported within PKIoverheid.
4.9.15 Procedure for suspension request
Suspension of certificates is not supported within PKIoverheid.
4.9.16 Limits on suspension period
Suspension of certificates is not supported within PKIoverheid.
4.10 Certificate Status Services
See sub-sections.
4.10.1 Operational characteristics
Revocation entries on a CRL or OCSP Response will not be removed until after the Expiry Date of the revoked Certificate.
Operational characteristics for CRL and any OCSP services for end-user certificates can be found in the CPS of the respective TSP.
4.10.2 Service availability
The OCSP service has the same availability as the CRL service. CRL service availability is described in Section 4.9.9.
4.10.3 Optional features
There are no further provisions for certificate status services on PKIoverheid Intermediate certificates, TSP Issuing certificates, or OCSP-Signing certificates.
4.11 End of subscription
No formal process exists for TSPs wanting to end issuing PKIoverheid certificates. Arrangements will be made between the PA PKIoverheid and the TSP wishing to end operations within PKIoverheid, to ensure continuity in PKIoverheid services towards existing end-entity certificate subscribers. Between PKIoverheid TSPs also exist business continuity agreements to ensure revocation and dissemination services continuity in case of disasters. These agreements also can be used for maintaining revocation and dissemination services for end-entity certificate subscribers whose TSP wishes to end issuing PKIoverheid certificates.
The process in case of ending the PKIoverheid ecosystem completely is described in Section 5.8.
4.12 Key escrow and recovery
See sub-sections.
4.12.1 Key escrow and recovery policy and practices
Key escrow is not in supported within the central hierarchy of PKIoverheid. Hence, no escrow policy and practices exist.
4.12.2 Session key encapsulation and recovery policy and practices
No stipulation.
5 Facility Management, Operational, and Physical Controls
This CPS contains a high-level description of the security measures taken by the PA.
The PA has implemented control measures in order to prevent loss, theft, damage or compromise of infrastructural assets and disruption of activities. The physical set-up is made up of various layers which require separate access control, each layer requiring a higher level of security. A series of measures have also been taken to protect against fire, natural disasters, failure of supporting facilities (such as electricity and telecommunication facilities), the risk of collapse, leakages, etc.
5.1 Physical controls
The secured environment of the root of the PKI for the government is set up based on the requirements formulated in the WebTrust Program for Certification Authorities, the Civil Service Information Security Classified Information Decree (Voorschrift Informatiebeveiliging Rijksdienst voor Bijzondere Informatie (VIR-BI)).
5.1.1 Site location and construction
Both primary and disaster recovery locations used for key material storage, and both key and certificate generation ceremonies, are undisclosed high-security facilities.
5.1.2 Physical access
Both primary and disaster recovery locations have multiple physical security zones, each with additional access controls.
5.1.3 Power and air conditioning
No stipulation.
5.1.4 Water exposures
No stipulation.
5.1.5 Fire prevention and protection
No stipulation.
5.1.6 Media storage
Media containing private key material is stored off-line in vaults with multiple security barriers, both in the primary and disaster recovery location.
5.1.7 Waste disposal
Media with private key material, as well as hard disks used in certificate issuing machines, are destroyed by organisations certified to dispose of hardware containing classified information. All paperwork related to PKIoverheid processes is destroyed by a specialized and certified organization as well.
5.1.8 Off-site backup
After each root and intermediate certificate key pair generation, the private keys are cloned and transferred to a high-security disaster recovery location.
5.2 Procedural controls
Trusted roles are assigned either by the PKIoverheid PA or management of the PKIoverheid Key Management team. Each role has authorizations based on the principle of least privilege.
The list of personnel appointed to trusted roles is maintained and reviewed annually.
The functions and duties performed by persons in trusted roles are distributed so that a lone person cannot subvert the security and trustworthiness of PKI operations.
5.2.1 Trusted roles
PKIoverheid recognizes the following trusted roles:
Key Management administrators with the following responsibilities:
- Installing and configuring CA software;
- Key generation and key back-up;
- Certificate generation;
- Certificate issuance;
- Certificate revocation;
- Preparation of ceremonies;
- Maintaining Key Management Handbook;
Key Management operators with the following responsibilities:
- Install, configure, and maintain infrastructure for the PKI Dissemination Services;
- Install, configure, and maintain infrastructure for the PKI Revocation Services;
PA Officers with the following responsibilities:
- Review certificate issuance and revocation requests;
- Verification of identities related to certificate issuance and revocation requests;
- Can represent the PA for certain tasks;
- Maintaining CPS and PoR;
- Governance on compliance;
PA with the following responsibilities:
- Accountable for PA Officers;
- Accountable for issued root, intermediate and TSP issuing certificates
- Accountable for compliance with the different PKI standards and trust frameworks;
- Responsible for strategic goals and tactical decisions;
External auditors with the following responsibilities:
- Perform annual Webtrust audit;
- Witnessing certain key ceremonies;
Penetration testers with the following responsibilities:
- Perform penetration tests on Dissemination and Revocation service infrastructures.
5.2.2 Number of persons required per task
The following tasks need multiple persons different trust roles (not limited to the specific PKI trust roles in Section 5.2.1) to complete. The total number of persons and actual roles involved in these tasks will remain undisclosed in this CPS.
- Issue a signing/revocation certification request to PKIoverheid Key Management;
- Access to any and all physical vaults containing material related to the key ceremony process;
- Access to all but the first security zone in the primary and disaster recovery facility used for key/certificate ceremonies and private key storage;
- Operation of CA systems used during key/certificate ceremonies (exluding ACC and TRIAL certificate ceremonies);
- Operation of HSM’s for key generation and cloning (exluding ACC and TRIAL key generation).
In case of key/certificate generation ceremonies (exluding ACC and TRIAL certificate ceremonies), there always is an independent external witness and a representative of the PA present. Any deviations from the ceremony script will be meticulously recorded. In addition to this, the entire ceremony is video recorded and saved. The recordings are stored and are available for playback for the Webtrust Auditor.
5.2.3 Identification and authentication for each role
Identification during key/certificate ceremonies is performed by verification of an identity document under article 1 of the Compulsory Identification Act (WID), limited to the following documents:
- a valid travel document referred to in the Passport Act (Paspoortwet);
- a valid driving licence issued on the basis of the Road Traffic Act (Wegenverkeerswet 1994) article 107.
Authentication on CA systems used in key/certificate ceremonies is done using multi-factor authentication.
5.2.4 Roles requiring separation of duties
Roles requiring separation of duties are task-specific. These are described in Section 5.2.2.
5.3 Personnel Security Controls
See sub-sections.
5.3.1 Qualifications, experience, and clearance requirements
The PKIoverheid PA verifies the identity and trustworthiness of all individuals assigned to trusted roles, as well as determines these persons perform their prospective job responsibilities competently and satisfactorily as required.
5.3.2 Background check procedures
Upon employment all Logius personnel have to show a Certificate of Conduct (Dutch: Verklaring omtrent gedrag). For specific trusted roles the PA can demand additional screening by either the General Intelligence Security Service (AIVD) or the Dutch Military Intelligence and Security Service (MIVD).
Additionally, the PA shall ensure that trusted personnel have no conflicting interests, in order to safeguard the impartiality of the activities of the PA.
5.3.3 Training requirements
No stipulation.
5.3.4 Retraining frequency and requirements
No stipulation.
5.3.5 Job rotation frequency and sequence
No stipulation.
5.3.6 Sanctions for unauthorized actions
No stipulation.
5.3.7 Independent contractor requirements
No stipulation.
5.3.8 Documentation supplied to personnel
No stipulation.
5.4 Audit logging procedures
See sub-sections.
5.4.1 Types of events recorded
The PKIoverheid PA records the following events:
- Root and Intermediate certificate and key lifecycle events, including:
- Certificate requests, renewal, and re-key requests, and revocation;
- Approval and rejection of certificate requests;
- Cryptographic device lifecycle management events; and
- Introduction of new Certificate Profiles and retirement of existing Certificate Profiles.
- TSP Issuing Certificate lifecycle management events, including:
- Certificate requests, renewal, and re-key requests, and revocation;
- Various verification activities stipulated in this Certification Practice Statement; and
- Approval and rejection of certificate requests.
Additionally, PKIoverheid Key Management records the following events:
- Root and Intermediate certificate and key lifecycle events, including:
- Key generation, backup, storage, recovery, archival, and destruction;
- Generation of Certificate Revocation Lists;
- Signing of OCSP Responses.
- TSP Issuing Certificate lifecycle management events, including:
- Issuance of Certificates;
- Generation of Certificate Revocation Lists; and
- Signing of OCSP Responses.
- Security events, including:
- Successful and unsuccessful PKI system access attempts;
- PKI and security system actions performed;
- Security profile changes;
- Installation, update and removal of software on a Certificate System;
- System crashes, hardware failures, and other anomalies;
- Firewall and router activities; and
- Entries to and exits from the Key Management facility.
All log records include at least the following elements:
- Date and time of event;
- Identity of the person making the journal record; and
- Description of the event.
5.4.2 Frequency of processing log
In general, logs are reviewed following an alarm or anomalous event, or when access is requested by auditors.
In the case of air-gapped CA systems, the log files of these systems are checked every key ceremony to confirm that no unauthorized changes have been made to these systems.
5.4.3 Retention period for audit log
Certificate and key lifecycle management event records related to PKIoverheid Root, Intermediate, and TSP Issuing Certificates as described in Section 5.4.1 are retained seven years after either the destruction of a corresponding Private Key, or the revocation or expiration of the certificate.
Security event records as set forth in Section 5.4.1 are retained a minimum of two years after the event occurred.
5.4.4 Protection of audit log
No stipulation.
5.4.5 Audit log backup procedures
No stipulation.
5.4.6 Audit collection system (internal vs. external)
No stipulation.
5.4.7 Notification to event-causing subject
No stipulation.
5.4.8 Vulnerability assessments
The PKIoverheid PA performs an annual Risk Assessment that:
- 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;
- assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and
- assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the PA has in place to counter such threats.
5.5 Records archival
See sub-sections.
5.5.1 Types of records archived
Audit logs as set forth in Section 5.4.1 are retained as described in Section 5.4.3. This can be in either archived or non-archived form in any part of the retention period.
In addition to this, the following information is archived:
- All documentation related to the security of Certificate Systems (related to Root, Intermediate, and TSP Issuing Certificates), Certificate Management Systems; and
- All documentation relating to the verification, issuance, and revocation of certificate requests and Certificates after the later occurrence of:
- such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or
- the expiration of the Subscriber Certificates relying upon such records and documentation.
5.5.2 Retention period for archive
Audit logs as set forth in Section 5.4.1 are retained as described in Section 5.4.3. This can be in either archived or non-archived form in any part of the retention period.
The archival period of all other archived information is at least two years, or seven years after its creation date, whichever comes last.
5.5.3 Protection of archive
Access to archives is only available to personnel in trusted roles, based on Access Control Lists (ACLs). All information systems containing archived information have additional security measures in place as stipulated in the governemental baseline for information security (Baseline Informatiebeveiliging Overheid).
5.5.4 Archive backup procedures
All information systems containing archives are backed-up automatically on a daily basis.
5.5.5 Requirements for time-stamping of records
No stipulation.
5.5.6 Archive collection system (internal or external)
No stipulation.
5.5.7 Procedures to obtain and verify archive information
No stipulation.
5.6 Key changeover
Private Keys corresponding to Public Keys in PKIoverheid Root, Intermediate, or TSP Issuing certificates normally are not reused once the term of validity has expired, or once the corresponding certificate has been revoked. When certificates are renewed, the key pair is also renewed. Only in rare circumstances key re-use will be allowed; see Section 4.7.
5.7 Compromise and disaster recovery
See sub-sections.
5.7.1 Incident and compromise handling procedures
An incident management process is in place based on the ITIL framework.
Different incident types and severity levels are defined, each with its own handling procedures. Compromises are always of type “security incident” and can lead to certificate revocations. See Section 4.9.1 for more information about revocation reasons.
When necessary the PKIoverheid PA will also notify the applicable Application Software Suppliers and/or Agentschap Telecom on incidents.
5.7.2 Computing resources, software, and/or data are corrupted
PKIoverheid has a hot-stand-by environment in a secondary high-security site with back-ups of all data. In case of faulty equipment or data corruption which can not be corrected on-sitet, processes can be diverted to the secondary environment. These disaster recovery procedures are tested on a yearly basis.
5.7.3 Entity private key compromise procedures
See Section 4.9.1.
5.7.4 Business continuity capabilities after a disaster
See Section 5.7.2.
5.8 CA or RA termination
The process for TSPs wanting to end issuing PKIoverheid certificates is described in Section 4.11.
If the Ministry of the Interior and Kingdom Relations itself decides to end operation of PKIoverheid, it can choose to either end PKIoverheid completely, or transfer it to another organization. In case of ending PKIoverheid completely, the following actions will be undertaken:
- All TSPs, end-entity certificate subcribers, and other relying parties within PKIoverheid, shall be informed six months before the service ends.
- 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. - When the service ends, all certificates that are still valid will be revoked.
- On the termination date, PKIoverheid ceases to distribute certificates and CRLs.
If the Ministry of the Interior and Kingdom Relations decides to transfer the PKIoverheid service to a different organization, all TSPs, end-entity certificate subcribers, and other relying parties within PKIoverheid, will be informed of this transfer at least 3 months in advance. The new organization will transfer the provisions from this CPS to its own CPS.
6 Technical Security Controls
See sub-sections.
6.1 Key pair generation and installation
See sub-sections.
6.1.1 Key pair generation
The key pairs meant for of the PA are generated during the various creation ceremonies. For this, only stand-alone computer systems are used. These computer systems are not connected to a network; all communication between systems takes place through media such as USB stick or smartcard. Because the generation and the use of the signing key of the PA takes place occasionally, the computer systems are only used for this purpose. The critical components of the computer systems are always stored in a safe, except for PKI ceremonies.
6.1.2 Private key delivery to subscriber
PKIoverheid Key Management does not create key pairs for PKIoverheid TSPs. Hence, no private keys need to be delivered to subscribers.
6.1.3 Public key delivery to certificate issuer
Public keys from PKIoverheid TSPs are delivered to PKIoverheid Key Management using secure email.
6.1.4 CA public key delivery to relying parties
No stipulation.
6.1.5 Key sizes
All PKIoverheid Root certificates, Intermediate certificates, TSP Issuing certificates, and OCSP Signing certificates are of type RSA and have a key length of 4096 bytes.
6.1.6 Public key parameters generation and quality checking
No stipulation.
6.1.7 Key usage purposes (as per X.509 v3 key usage field)
See keyUsage
field descriptions in Section 7.
6.2 Private Key Protection and Cryptographic Module Engineering Controls
See sub-sections.
6.2.1 Cryptographic module standards and controls
Private keys related to PKIoverheid Root and Intermediate certificates always reside on a Hardware Security Module (HSM) that meets either the requirements identified in FIPS PUB 140-2 Level 3, or ISO 15408 at evaluation guarantee level EAL 4+ or equivalent security criteria.
6.2.2 Private key (n out of m) multi-person control
All operations with private keys related to PKIoverheid Root and Intermediate certificates need multiple authorized people from different teams to be present and unlock the needed functionalty.
6.2.3 Private key escrow
Escrow of private keys related to PKIoverheid Root and Intermediate certificates is not allowed.
6.2.4 Private key backup
Cloned private keys related to all the PKIoverheid Root and Intermediate certificates, but excluding TRIAL certificates, are stored in the PKIoverheid Disaster Recovery location with the same (technical) security controls as the operational private keys. The private keys related to the PKIoverheid TRIAL Root and Intermediate certificates have no backup.
6.2.5 Private key archival
When a PKIoverheid Root or Intermediate certificate expires or is revoked, its private key will not be archived but destroyed in a timely fashion. See Section 6.2.10 for more information on private key destruction.
6.2.6 Private key transfer into or from a cryptographic module
Cloning of private keys between the primary HSM and Disaster Recovery HSM is the only transfer operation of PKIoverheid private keys allowed.
6.2.7 Private key storage on cryptographic module
The private keys related to all PKIoverheid Root and Intermediate certificates are stored on an HSM.
6.2.8 Method of activating private key
Private keys related to PKIoverheid Root and Intermediate certificates are off-line. Activation of these keys therefore only happens during key ceremonies.
Only the private keys related to PKIoverheid TRIAL Root and Intermediate certificates can be activated directly by members of the PKIoverheid Key Management team, the procedure of which is described in the Key Management Handbook.
6.2.9 Method of deactivating private key
No stipulation.
6.2.10 Method of destroying private key
Destroying a Private Key comprises of removing it from both active and back-up HSMs.
6.2.11 Cryptographic Module Rating
See Section 6.2.1.
6.3 Other aspects of key pair management
See sub-sections.
6.3.1 Public key archival
Public keys related to PKIoverheid Root, Intermediate, and TSP Issuing certificates are only archived as part of the certificates themselves.
6.3.2 Certificate operational periods and key pair usage periods
For PKIoverheid certificates the following operational periods (certificate validity
field) apply:
- Root certificates: 15 years;
- Intermediate certificates: 15 years minus 1 day;
- TSP Issuing certificates: 15 years minus 2 days;
- OCSP Responder certificates: 365 days.
6.4 Activation data
Activation data refers to data values other than whole Private Keys that are required to operate Private Keys or cryptographic modules containing Private Keys. Examples of activation data include, but are not limited to, PINs, passphrases, and portions of Private Keys used in a key-splitting regime.
6.4.1 Activation data generation and installation
Activation data is generated in accordance with the specifications of the HSM.
6.4.2 Activation data protection
Activation data is stored in separate seal bags in separate compartments in different PKIoverheid secured safes.
6.4.3 Other aspects of activation data
No stipulation.
6.5 Computer security controls
See sub-sections.
6.5.1 Specific computer security technical requirements
PKIoverheid Key Management has implemented all technical computer security requirements as described in the “Network and Certificate System Security Requirements” CA/Browser Forum document, as well as relevant technical ISO 27001 requirements.
6.5.2 Computer security rating
The hardware and software used in the central hierarchy for the key management is classified by the Nationaal Bureau voor Verbindingsbeveiliging (NBV) at level “Staatsgeheim confidentieel”. This level is Comparable to “Confidential” in UK/US government classifications.
6.6 Life cycle technical controls
See sub-sections.
6.6.1 System development controls
Changes to information systems are implemented using a formal change management process, including a separate environment for acceptance testing. Before entering the formal change management process, initial development and testing is done on another environment for development purposes.
6.6.2 Security management controls
The PKIoverheid team has implemented all security management controls described in Baseline Informatiebeveiliging Overheid (BIO) which isbased on ISO 27001. For publicly-trusted certificates this also includes the security management controls described in the CA/Browser Forum “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates”.
6.6.3 Life cycle security controls
The PKIoverheid team has implemented all security life-cycle controls described in the Baseline Informatiebeveiliging Overheid (BIO) which is based on ISO 27001. For publicly-trusted certificates this also includes the security life-cycle controls described in the CA/Browser Forum “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates”.
6.7 Network security controls
The PKIoverheid team has implemented all security network controls described in Baseline Informatiebeveiliging Overheid (BIO) which isbased on ISO 27001, as well as the CA/Browser Forum “Network and Certificate System Security Requirements” for its network-connected systems.
6.8 Time-stamping
PKIoverheid does not support a time-stamping service as part of its services portfolio.
For time-stamping of its own OCSP responses a trustworthy NTP server is used. Dates in PKIoverheid Root, Intermediate, and TSP Issuing certificates, are entered manually and based on the time displayed on ceremony member’s mobile devices which are synchronized with the network time of their mobile telephony providers.
7 Certificate and CRL, and OCSP profiles
See sub-sections.
7.1 Certificate profile
The table below contains all fields to be used in PKIoverheid certificates. PKIoverheid certificates do not contain any fields and extensions other than those described in the table. Contents and usage of certificate fields can differ per PKIoverheid certificate type (for an overview, see Section 1.1 of this CPS). For each separate certificate field the table shows which usages and contents are applicable for which certificate type. All fields comply with IETF CRL Profile RFC 5280.
Note: All actual field values can be found on https://cert.pkioverheid.nl.
Field / Attribute | Value |
---|---|
signatureValue |
All certificates: Signature bit string |
signatureAlgorithm |
All certificates: algorithmIdentifier field contains algorithm field with value sha256WithRSAEncryption (OID: 1.2.840.113549.1.1.11) and parameters field with value NULL |
tbsCertificate:version |
All certificates: 3 (integer 2) |
tbsCertificate:serialNumber |
All certificates: serialNumber field in certificates issued after 2019-03-01 have 159 bits of entropy; certificates issued before that date may contain less. |
tbsCertificate:signature |
All certificates: algorithmIdentifier field contains algorithm field with value sha256WithRSAEncryption (OID: 1.2.840.113549.1.1.11) and parameters field with value NULL |
tbsCertificate:issuer |
All certificates: Identical to tbsCertificate:subject attribute of issuing certificate. |
tbsCertificate:validity:notBefore |
All certificates: Date of issuance in UTC-encoded Generalized Time |
tbsCertificate:validity:notAfter |
Note: All values are in UTC-encoded Generalized Time. |
tbsCertificate:subject:countryName |
All certificates: NL |
tbsCertificate:subject:commonName |
Note: <n> is the incarnation number of the certificate, and <m> is the OCSP Status server number in a cluster. |
tbsCertificate:subject:organizationName |
EV+G3+Private Root and Intermediate: Staat der Nederlanden TRIAL Root and Intermediate: PKIoverheid TRIAL All TSP: <TSP name> All OCSP -Signing: Staat der Nederlanden |
tbsCertificate:subject:organizationIdentifier |
G3+Private+TRIAL TSP: <NTR number> or <Government Identification Number> of TSP in accordance with syntax from paragraph 5.1.4 of ETSI EN 319 412-1 All other: Attribute not included |
tbsCertificate:subjectPublicKeyInfo |
All certificates: algorithmIdentifier field contains RSA (OID: 1.2.840.113549.1.1.1) and subjectPublicKey field contains the 4096-bit public key of the subject. |
tbsCertificate:extensions:authorityKeyIdentifier |
extnID: 2.5.29.35 critical: FALSE extValue:
|
tbsCertificate:extensions:subjectKeyIdentifier |
extnID: 2.5.29.14 critical: FALSE extValue:
|
tbsCertificate:extensions:keyUsage |
extnID: 2.5.29.15 critical: TRUE extValue:
|
tbsCertificate:extensions:certificatePolicies |
extnID: 2.5.29.32 critical: FALSE extValue: For each of the policy identifiers below a separate PolicyIdentifiers:
|
tbsCertificate:extensions:basicConstraints:cA |
extnID: 2.5.29.19 critical: TRUE extValue: * All OCSP-Signing: |
tbsCertificate:extensions:cRLDistributionPoints |
extnID: 2.5.29.31 critical: FALSE extValue:
|
tbsCertificate:extensions:extKeyUsage |
extnID: 2.5.29.37 critical: FALSE extValue:
|
tbsCertificate:extensions:authorityInfoAccess |
extnID: 1.3.6.1.5.5.7.1.1 critical: FALSE extValue:
|
tbsCertificate:extensions:qcStatements |
extnID: 1.3.6.1.5.5.7.1.3 critical: FALSE extValue:
|
tbsCertificate:extensions:id-pkix-ocsp-nocheck |
extnID: 1.3.6.1.5.5.7.48.1.5 critical: FALSE extValue:
|
7.1.1 Version number(s)
See Section 7.1.
7.1.2 Certificate extensions
See Section 7.1.
7.1.3 Algorithm object identifiers
See Section 7.1.
7.1.4 Name forms
See Section 7.1.
7.1.5 Name constraints
See Section 7.1.
7.1.6 Certificate policy object identifier
See Section 7.1.
A complete list of all PKIoverheid OIDs can be found in the PKIoverheid OID Registration document. See Section 2.1 for the location of this document.
7.1.7 Usage of Policy Constraints extension
The Policy Constraints extension is not used within PKIoverheid.
7.1.8 Policy qualifiers syntax and semantics
See Section 7.1.
7.1.9 Processing semantics for the critical Certificate Policies extension
No stipulation.
7.2 CRL profile
The table below contains all fields to be used in PKIoverheid Certificate Revocation Lists (CRLs). PKIoverheid CRLs do not contain any fields and extensions other than those described in the table. Contents and usage of certificate fields can differ per PKIoverheid certificate type (for an overview, see Section 1.1 of this CPS). For each separate CRL field the table shows which usages and contents are applicable for which certificate type. All fields comply with IETF CRL Profile” >RFC 5280.
Field / Attribute | Value |
---|---|
tbsCertList:version |
All CRLs: 2 (integer 1) |
tbsCertList:signature |
All CRLs: algorithmIdentifier contains algorithm field with value sha256WithRSAEncryption (OID: 1.2.840.113549.1.1.11) and parameters field with value NULL |
tbsCertList:issuer:commonName |
|
tbsCertList:issuer:organization |
|
tbsCertList:issuer:country |
All CRLs: NL |
tbsCertList:thisUpdate |
All CRLs: Effective date of the CRL in UTC-encoded Generalized Time |
tbsCertList:nextUpdate |
All CRLs: The latest date on which an update can be expected in UTC-encoded Generalized Time |
tbsCertList:revokedCertificates |
All CRLs: List of all revoked certificates issued by
|
tbsCertList:crlExtensions:authorityKeyIdentifier |
All CRLs:
Note: Actual values can be found on https://cert.pkioverheid.nl. |
tbsCertList:crlExtensions:crlNumber |
All CRLs:
|
signatureAlgorithm |
All CRLs: algorithmIdentifier field has the value sha256WithRSAEncryption (OID: 1.2.840.113549.1.1.11) |
signatureValue |
All CRLs: Signature bit string |
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.
Field / Attribute | Value |
---|---|
responseStatus:oCSPResponseStatus |
Integer status code as described in RFC 6960 |
responseBytes:responseType |
ocspBasic (OID: 1.3.6.1.5.5.7.48.1.1) |
responseBytes:response:tbsResponseData:version |
Equal to DEFAULT value of 1 (integer 0), so not encoded in BER/DER |
responseBytes:response:tbsResponseData:responderId |
Contains byKey [2] choice field with an OCTET STRING as keyHash value |
responseBytes:response:tbsResponseData:producedAt |
The time at which the OCSP responder signed the response in UTC-encoded Generalized Time |
responseBytes:response:tbsResponseData:responses: singleResponse:certId:hashAlgorithm |
algorithmIdentifier contains algorithm field with value sha1 (OID: 1.3.14.3.2.26) and parameters field with value NULL |
responseBytes:response:tbsResponseData:responses: singleResponse:certId:issuerNameHash |
OCTET STRING of the issuer’s Name Hash |
responseBytes:response:tbsResponseData:responses: singleResponse:certId:issuerKeyHash |
OCTET STRING of the issuer’s Key Hash |
responseBytes:response:tbsResponseData:responses: singleResponse:certId:serialNumber |
INTEGER of the certificate’s Serial Number |
responseBytes:response:tbsResponseData:responses: singleResponse:certStatus |
Contains one of the ENUMERATED values below indicating the most appropriate reason for revocation of the certificate:
Note: See Section 4.9.1 for a description of all revocation reasons. |
responseBytes:response:tbsResponseData:responses: singleResponse:thisUpdate |
The most recent time at which the status being indicated is known by the responder to have been correct in UTC-encoded Generalized Time |
responseBytes:response:tbsResponseData:responses: singleResponse:nextUpdate |
thisUpdate value +2 days in UTC-encoded Generalized Time |
responseBytes:response:signatureAlgorithm |
Contains algorithm field with value sha256WithRSAEncryption (OID: 1.2.840.113549.1.1.11) and parameters field with value NULL |
responseBytes:response:signature |
Signature BIT STRING (160bits for SHA1) |
responseBytes:response:certs |
Certificate used to sign the OCSP Response is included. If that certificate was signed by a PKIoverheid Intermediate certificate, then that Intermediate certificate is included as well, thus adding a complete trust chain up to (but not including) the Root certificate, |
7.3.1 Version number(s)
See Section 7.3.
7.3.2 OCSP extensions
If applicable, see Section 7.3.
8 Compliance Audit and Other Assessment
See sub-sections.
8.1 Frequency or circumstances of assessment
The PA of PKIoverheid complies with the requirements described in the latest version of the WebTrust Principles and Criteria for Certification Authorities. Each year, the PA of PKIoverheid undergoes an full period-of-time audit for this.
The PA PKIoverheid actively monitors the changes in the WebTrust Principles that affect this CPS. The PA PKIoverheid also actively monitors changes in the Baseline Requirements of the CA / Browser Forum that affect this CPS and the Programme of Requirements of PKIoverheid. The impact of these changes on the CPS and PoR of PKIoverheid are assessed and, if deemed necessary, incorporated in the PoR and/or this CPS.
The PA PKIoverheid also conforms with established government policy in relation to information security and privacy.
8.2 Identity/qualifications of assessor
Audits are performed by an external certified WebTrust for CAs auditor. These auditors meet the requirements of Section 8.2 of the CA/Browser Forum Baseline Requirements and are experienced in performing information security audits, and have significant experience with PKI and cryptographic technologies.
8.3 Assessor’s relationship to assessed entity
The assessor performing the audit of PKIoverheid is an independent third party.
8.4 Topics covered by assessment
The following assessment frameworks are used to audit PKIoverheid certificates capable of issuing other certificates:
- “WebTrust Principles and Criteria for Certification Authorities” Framework (WTCA)
- “WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security” Framework (WTSSL)
- “WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL” Framework (WTEV)
The table below shows which assessment framework is used to audit which type of PKIoverheid certificate capable of issuance.
Certificate type | WTCA | WTSM | WTBR |
---|---|---|---|
EV Root | Yes | Yes | Yes |
EV Intermediate | Yes | Yes | No[1] |
G3 Root + Intermediates | Yes | Yes | No |
Private Root + Intermediates | Yes | No | No |
TRIAL Root + Intermediates | No | No | No |
The latest version of these assessment frameworks are being used. Topics covered in these assessment frameworks can be found on the website of Chartered Professional Accountants (CPA) Canada (https://www.cpacanada.ca).
[1] Currently the only remaining EV Intermediate certificate is “CA Server 2020” which does not actually issue EV certificates. Therefore WTEV is not applicable although it technically is in the EV hierarchy.
8.5 Actions taken as a result of deficiency
When an Auditor reports a deficiency, the PKIoverheid PA will develop a Corrective Action Plan (CAP) to correct the deficiency, which could involve changing its policies or practices, or both. The amended policies and/or practices will be put into operation and the Auditor will be required to verify that the deficiency is no longer present.
8.6 Communicating of results
Through a WebTrust seal, published yearly on the Logius website, the PA PKIoverheid demonstrates that it meets the WebTrust requirements. The PA publishes this seal and accompanying Management Assertion no longer than 3 months after expiry of the previous audit period.
Audit Statements of all Root, Intermediate and TSP Issuing certificates in scope of WebTrust are submitted to the Common Certificate Authority Database (CCADB).
8.7 Self-audits
The PKIoverheid PA self-audits all certificates submitted to a CT-Log through automated linting software.
Additionally, the PKIoverheid PA performs a yearly self-assessment based on the Mozilla “Template for Compliance Self-Assessment” (see: https://docs.google.com/spreadsheets/d/1ExZE6PWIBM8rV9c6p6fFxOWmZyvf6X4ucMQRv7usHEk/edit?usp=sharing).
9 Other Business and Legal Matters
See sub-sections.
9.1 Fees
See sub-sections.
9.1.1 Certificate issuance or renewal fees
No stipulation.
9.1.2 Certificate access fees
All PKIoverheid Root, Root, and OCSP SIgning certificates contain a reference to this CPS. No fee is charged for consulting these certificates or the information referred to. This applies to:
- consulting the certificates,
- consulting the revocation status information (CRLs or OCSP),
- consulting the Programme of Requirements: Certificate Policies, and
- consulting this CPS.
9.1.3 Revocation or status information access fees
No stipulation.
9.1.4 Fees for other services
No stipulation.
9.1.5 Refund policy
No stipulation.
9.2 Financial responsibility
See sub-sections.
9.2.1 Insurance coverage
In terms of liability, the general rules of Dutch law apply with respect to the content and scope of the statutory obligation to pay compensation. The Ministry of the Interior and Kingdom Relations and a TSP enter into an agreement or contract concerning participation of the relevant TSP in PKIoverheid. In essence, this means that the TSP is obliged to provide services under the conditions stipulated by the Ministry of the Interior and Kingdom Relations, particularly the conditions laid down in the Programme of Requirements. In this respect, the PA is the point of contact for the TSP.
Provisions regarding the liability of the Ministry of the Interior and Kingdom Relations towards a TSP are included in an agreement or contract between the Ministry of the Interior and Kingdom Relations and the TSP. The requirements that the liability of the TSP must meet are stated in the Programme of Requirements.
9.2.2 Other assets
No stipulation.
9.2.3 Insurance or warranty coverage for end-entities
The TSP enters into agreements with subscribers and relying parties. Also laid down in these agreements is the liability of the TSP in respect of subscribers and relying parties. The requirements that this liability must meet are included in the General Provisions of the Programme of Requirements.
The State of the Netherlands has not taken out insurance for claims for compensation in respect of any liability.
9.3 Confidentiality of business information
See sub-sections.
9.3.1 Scope of confidential information
No stipulation.
9.3.2 Information not within the scope of confidential information
No stipulation.
9.3.3 Responsibility to protect confidential information
The PA PKIoverheid handles company data confidentially. Only employees of the PA PKIoverheid have access to this data.
Company data, such as audit reports and Corrective Action Plans of TSPs will be encrypted before exchange will take place.
9.4 Privacy of personal information
Unlike the TSP, PA PKIoverheid does not issue certificates to natural persons. A register with the personal data of certificate users is therefore not available.
9.4.1 Privacy plan
Not applicable.
9.4.2 Information treated as private
Not applicable.
9.4.3 Information not deemed private
Not applicable.
9.4.4 Responsibility to protect private information
Not applicable.
9.4.5 Notice and consent to use private information
Not applicable.
9.4.6 Disclosure pursuant to judicial or administrative process
Not applicable.
9.4.7 Other information disclosure circumstances
Not applicable.
9.5 Intellectual property rights
This document is made available to the general public under the CC-BY-ND 4.0 license.
9.6 Representations and warranties
See sub-sections.
9.6.1 CA representations and warranties
TSP Issuing certificates issued by the PKIoverheid PA cannot be used to create additional sub-CAs. For a description of aditional safeguards, please refer to the relevant Certification Practice Statements of the PKIoverheid Trust Service Providers.
9.6.2 RA representations and warranties
No stipulation.
9.6.3 Subscriber representations and warranties
No stipulation.
9.6.4 Relying party representations and warranties
No stipulation.
9.6.5 Representations and warranties of other participants
No stipulation.
9.7 Disclaimers of warranties
See Section 9.2.
9.8 Limitations of Liability
See Section 9.2.
9.9 Indemnities
See Section 9.2.
9.10 Term and termination
See sub-sections.
9.10.1 Term
This CPS is valid as from the date of entry into force. The CPS is valid for the period of time that the services of PKIoverheid continue or until the CPS is replaced by a newer version. The latest version can always be found in the electronic repository mentioned in Section 2.1.
9.10.2 Termination
No stipulation.
9.10.3 Effect of termination and survival
No stipulation.
9.11 Individual notices and communications with participants
If TSPs have any questions, they can contact the PA PKIoverheid.
Regular communication takes place by email between the PA and the TSPs that participate in the PKIoverheid framework.
Besides communications with the TSPs, frequent contact also takes place with AT Radiocommunications Agency (see also: https://www.agentschaptelecom.nl/onderwerpen/zakelijk-gebruik/eidas-elektronische-vertrouwensdiensten/trust-service-providers) and the auditor(s) of the participating TSPs.
9.12 Amendments
See sub-sections.
9.12.1 Procedure for amendment
Within PKIoverheid there exist three different policy documents:
- this CPS,
- the Program of Requirements for PKIoverheid TSPs, and
- the Registration of PKIoverheid OIDs.
Procedures for amendments differ between these three documents.
This CPS
The Ministry of the Interior and Kingdom Relations is responsible for this CPS. The Ministry has delegated this task to Logius. This also includes the approval of changes to this CPS.
Program of Requirements for PKIoverheid TSPs
Consultation structure
- Within the PKIoverheid framework the following bodies are involved in the change management of the Programme of Requirements: The PKIoverheid Change Council and PKIoverheid Framework Council.
- The Framework Council comprises a delegation of the PA and the TSPs that participate in the PKIoverheid framework. The Change Council is also formed by a delegation of the PA and TSPs and the opportunity is given to invite experts.
- Auditors of TSPs that participate in the PKIoverheid framework may join in the deliberations of the Change Council and/or Framework Council as a observer. When an auditor is present, he/she will have familiarised him/herself with the change proposals and is able to at least indicate whether a new or amended standard can be audited.
- The specific aim of these bodies is to facilitate consensus on changes to the Programme of Requirements (PoR). The Change Council congregates to discuss draft change proposals and to reach, as far as possible, consensus on the final change proposals.The Framework Council is a platform where announcements concerning the PKIoverheid framework by the PA are made and a proposed decision is taken on the inclusion of final change proposals in the next version of the PoR, including an effective date.
- In principle, the Framework Council is convened twice a year in relation to the publication of a new version of the Programme of Requirements of PKIoverheid.
- In any case, the Change Council meets one month before a Framework Council meeting, but can be convened more often in order to discuss change proposals which will have a significant impact.
- Separate meeting are organised to discuss specific subjects, which are not directly related to current PoR changes.
Decision-making
- During the Framework Council meeting, based on a consensus, an attempt is made to take a proposed decision concerning the content and effective date of changes to the Programme of Requirements.
- Changes to the PoR are enforced by the Ministry of the Interior and Kingdom Relations, which as the owner has ultimate responsibility for the PKIoverheid framework and makes decisions about enforcing change proposals, sometimes through an accelerated change procedure. The PA provides the owner with advice in this regard.
- Each proposed change that has been discussed by the Framework Council or as a result of the accelerated change procedure is submitted by the PA for approval to an official appointed by the Ministry of the Interior and Kingdom Relations, along with a recommendation from the PA and the opinion of the TSPs. Currently, this is the director of the directorate for Information Society and Government from the Ministry of the Interior and Kingdom Relations.
- In addition, the official appointed by the Ministry of the Interior and Kingdom Relations will be informed about change proposals that have (temporarily) been revoked.
- If there is a disagreement with the TSPs on a change proposal, the decision will be justified by the official from the Ministry of the Interior and Kingdom Relations.
- After approval is given by the official appointed by the Ministry of the Interior and Kingdom Relations, the change will be published by the PA on the website of Logius in a way that is clearly identifiable and uses comprehensible language; also stated is when the change shall take effect.
- In addition, the PA informs the TSP contact persons and the party that submitted the change proposal electronically and/or in writing of the decision that has been taken.
- If there is a new version of the PoR, prior to publication a formal signature is required by both the director of Logius and the official appointed by the Ministry of the Interior and Kingdom Relations. In the event of an accelerated change procedure, approval of changes by email will suffice.
- The official appointed by the Ministry of the Interior and Kingdom Relations reserves the right to make changes to the PoR autonomously in the context of an (imminent) incident, emergency or crisis.
Framework
- TSPs must comply with the content and effective date of changes approved or published by the official appointed by the Ministry of the Interior and Kingdom Relations.
- When a TSP cannot meet the effective date of a new or changed requirement, the TSP must ask for formal dispensation for this from the PA PKIoverheid.
- A request for dispensation is formally submitted at the latest one week after the convening of the Framework Council and must be announced during the meeting.
- Dispensation has to be requested electronically and/or in writing from the PA PKIoverheid.
- The PA submits the proposed granting of dispensation for approval to the official appointed to that end by the Ministry of the Interior and Kingdom Relations.
- The PA shall respond electronically and/or in writing stipulating whether the request is honoured or refused. The auditor of the TSP will receive a copy of this message.
Change proposals
- The following parties can submit a change proposal regarding a part of, or a provision in the Programme of Requirements (PoR) through the usual or accelerated change procedure:
- the Ministry of the Interior and Kingdom Relations;
- the PA PKIoverheid (PA);
- TSPs within the PKI for the government that use the PoR.
- The PA can submit change proposals based on the input from end users or other stakeholders. This will be clearly indicated in the change request.
- Change requests are usually approved by the Change Council and Framework Council. If a change cannot wait until the next version of the PoR, an abbreviated change procedure is available.
- A change proposal can be submitted by completing the request form “Change proposal Programme of Requirements” and sending this to the PA. This form can be found on the PA’s website or can be requested directly from the PA.
- The PA handles a submitted change proposal regarding a part of, or a provision in the PoR in accordance with documented internal processes. In the event of an actual (material) change the PA will analyse the proposal and has the ability to outright reject said proposal. If the PA agrees with the (goal of the) change propopsal it will issue a positive recommendation, including text proposal, impact analysis (for instance: effective dates and possible dispensation) and reasoning. These are submitted to the TSPs for consultation.
Regular change procedure
- In principle, a new version of the PoR is published twice a year. A proposed decision regarding inclusion of a new or amended requirement in the PoR is taken during the meeting of the Framework Council prior to publication.
- Change proposals are sent to the TSPs at least ten weeks before the publication of the new PoR version is due.
- Change requests submitted after this date will not be considered for publication in the next version of the PoR, unless the PA and TSPs agree unanimously that this change can still be included.
- TSPs have five weeks to analyse change proposals and to give feedback to the PA.
- This feedback is discussed during the Change Council meeting prior to the meeting of the Framework Council.
- Taking the Change Council input into consideration, change proposals are finalised.
- The PA sets the dates for the Change and Framework Council meetings. The meetings will take place as soon as possible after the latest draft proposals for the next version of the PoR have been distributed. There will be a minimum of 2 weeks between the Change Council meeting and the Framework Council meeting.
- The final change proposals are sent to the TSPs and the auditors no later than 2 working days after the Change Council meeting, along with the agenda for the Framework Council meeting.
- The response time of TSPs to the agenda and the final change proposals is at least one week.
- TSPs are expected not to put forward new insights once the final change proposals have been completed and distributed. This is meant to prevent the PA and other TSPs being forced to take a decision during the Framework Council meeting without the possibility to carefully consider the content of the new proposal.
- If the delegation from a TSP cannot be present during a Change or Framework Council meeting, the TSP contact person is expected to elaborate on their point of view in advance in writing concerning the content and the effective date of changes.
- Following the Framework Council meeting, the PoR will be published as soon as possible.
- The effective dates of changes are specifically included in the PoR.
Ordinary change process in weeks
The regular change process has the following chronological steps and lead times in weeks. Starting point is the final date for submission of concepts:
- +5 weeks for TSPs for submitting feedback;
- +1 week before earliest date of the Change Council Meeting;
- +2 weeks to submit final change proposals;
- any number of weeks for TSPs to submit final feedback and agenda items;
- +1 week before earliest date of the Framework Council Meeting;
- any number of weeks for publishing the new PoR;
- +4 weeks before earliest effective date for new changes.
Figure 3 Image with overview of ordinary change process in weeks
Accelerated change procedure
- Changes are usually dealt with through the regular change procedure. In the event of an (imminent) incident, change in external requirements (For instance, a change in browser policy), emergency or crisis, the official appointed by the Ministry of the Interior and Kingdom Relations can make changes autonomously. In addition, an accelerated change procedure can be followed, if it is necessary to enforce a change well before publication of a new version of the PoR.
- Using the utmost caution the PA decides when it is necessary to follow an accelerated change procedure.
- An accelerated change procedure entails the following process:
- The TSPs, the auditors of the TSPs and the official appointed by the Ministry of the Interior and Kingdom Relations are informed by email of the intention of the PA to publish a change through an accelerated change procedure on the Logius website, along with the change request.
- TSPs have at least one week to submit objections to the content and/or effective date of this change.
- Any objections will be carefully considered by the PA PKIoverheid which, in close consultation, shall endeavour to provide sound advice.
- The decision making process followed by the Ministry of the Interior and Kingdom Relations is described in the paragraph entitled “Decision-making”.
- The PA publishes the change on the website and communicates this to the TSPs. The TSPs must adhere to the content and the effective date of the change published on the Logius website.
Miscellaneous
- The PoR and the approved changes can be obtained in electronic form via the Internet on the PA’s website: http://www.logius.nl/pkioverheid.
- In the PoR, reference is made to this change procedure, which is included in the CPS of PKIoverheid.
Registration of PKIoverheid OIDs
The PKIoverheid PA is itself fully responsible for maintaining and decision making regarding the PKIoverheid OID naming arc.
9.12.2 Notification mechanism and period
Any changes to PKIoverheid policy documents are announced through the agreed channels with all PKIoverheid TSPs.
9.12.3 Circumstances under which OID must be changed
No stipulation.
9.13 Dispute resolution provisions
Dispute resolution provisions are described in various individual agreements between Logius PKIoverheid and its TSPs.
9.14 Governing law
Dutch law applies.
9.15 Compliance with Applicable Law
The PA function is performed by Logius. Logius is a digital government service and is part of the Ministry of the Interior and Kingdom Relations Government organizations. The General Administrative Law Act (in Dutch) applies to Logius (see: https://wetten.overheid.nl/BWBR0005537/2018-09-19).
9.16 Miscellaneous provisions
See sub-sections.
9.16.1 Entire agreement
No stipulation.
9.16.2 Assignment
No stipulation.
9.16.3 Severability
No stipulation.
9.16.4 Enforcement (attorneys’ fees and waiver of rights)
No stipulation.
9.16.5 Force Majeure
No stipulation.
9.17 Other provisions
No stipulation.