PKIoverheid Programme of Requirements 5

Table of Contents

1. INTRODUCTION

1.1 Overview

This is PKIoverheid Requirements document describes all the requirements for Trust Service Providers (TSP) providing services within the PKIoverheid trust hierarchy. It acts as a Certificate Policy (CP) for PKIoverheid TSPs. Within the PKIoverheid trust hierarchies a distinction is made between various domains:

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Organization Services certificates (previously 3b)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2019 Autonomous Devices certificates (previously 3d)
• G3 2023 Organization Person certificates
• G3 2023 Organization Services certificates
• G3 2023 Citizen certificates
• G3 2023 S/MIME certificates
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Private Person certificates (previously 3i)

The PKIoverheid Requirements document structure complies with RFC 3647.

1.2 Document name and identification

1.2.1 Revisions

Version 1.0

First version.

Version 1.0 to 1.1

New

• Added definition of Fully-Qualified Domain Name (FQDN).

Modifications

• Requirement 4.4.1-1.
• Comments on attribute subject:commonName in the certificate profile of certificates under domains Organization Person and Organization Services.
• Explanation and comments on attribute subjectAltName:otherName in the certificate profile of certificates under domain Organization Person.

Removals

None.

Editorial

Some editorial changes were made but none have an effect on the informational contents of the document.

Version 1.1 to 1.2

New

None.

Modifications

• Changes in requirements 3.3.1-1, 3.3.1-2, 6.1.1-1, 6.1.1-2, 6.1.1-3, 6.1.2-1, 6.1.5-1, 6.1.7-1, 6.2.3-1, 6.2.3-2, 6.2.3-3, 6.2.3-4, 6.2.4.2-1, 6.2.5-1, 6.3.1-1, 9.6.1-1, 9.6.1-2, 9.6.1-4, 9.8-1, and9.8-2.
• Comments on attribute signature in the certificate profile of certificates under domains Organization Person, Organization Services, and Citizen.
• Comments on attribute certificatePolicies in the certificate profile of certificates under domains Organization Person and Organization Services.

Removals

None.

Editorial

Some editorial changes were made but none have an effect on the informational contents of the document.

Version 1.2 to 2.0

New

• Requirement 4.9.3-1.
• Attribute authorityInfoAccess under CRL extensions.

Modifications

• Paragraph 1.3;
• Changes in requirements 3.2.2-2, 3.2.3-1, 3.2.5-1, 3.2.5-2, and 4.5.2-1.
• Comments on attribute subject:organizationalUnitName in the certificate profile of certificates under domain Organization Person.
• Comments on attribute certificatePolicies in the certificate profile of certificates under domain Organization Person.
• Comments on attribute subjectAltName:rfc822Name in the certificate profile of certificates under domain Organization Person.
• Explanation and comments on attribute extKeyUsage in the certificate profile of certificates under domain Organization Person.

Removals

• Comments on attribute subject:commonName in the certificate profile of certificates under domain Organization Services.

None.

Editorial

Some editorial changes were made but none have an effect on the informational contents of the document.

Version 2.0 to 2.1

New

None.

Modifications

None.

Removals

None.

Editorial

Some editorial changes were made but none have an effect on the informational contents of the document.

Version 2.1 to 3.0

New

• Definition added of Autonomous Device Certificate, Profession-Related Certificates, Authorized Representative, Enhanced Extended Validation Certificates Policy – EVCP+, Extended Validation SSL Certificates, Generic TopLevelDomain (gTLD), Country code TopLevelDomein (ccTLD), organization-related Certificates, Government, Personal Certificates and Services Certificate.
• Attribute subjectAltName:dNSName in the certificate profile of certificates under domain Organization Services.
• Requirement 4.9.2-1.

Modifications

• Changes in requirements 4.9.2-1 and 6.2.11-3.
• Comments on attribute signature in the certificate profile of certificates under domains Organization Person, Organization Services, and Citizen.

Removals

None.

Editorial

Some editorial changes were made but none have an effect on the informational contents of the document.

Version 3.0 to 3.1

New

• Added requirements 3.2.1-1, 4.9.7-1, 4.9.9-4, 4.9.9-6, 6.3.2-2, 6.5.1-1, 6.5.1-2, 9.17-2, 9.17-3, and 9.17-4.
• Added definition of Multi-factor authentication and Reseller.

Modifications

• Added requirements 4.9.1-1 and 6.3.2-1.
• Comments on attribute serialNumber in the certificate profile of certificates under domains Organization Person, Organization Services, Citizen, Autonomous Devices, and EV Server.

Removals

None.

Editorial

Some editorial changes were made but none have an effect on the informational contents of the document.

Version 3.1 to 3.2

New

• Added requirements 5.2.4-2, 5.4.1-1 (effective date no later than 1-6-2012), 6.1.1-4 (effective date no later than is 1-7-2012), 6.5.1-3 (effective date no later than is 1-7-2012), 6.7.1-1 (effective date no later than 1-7-2012), 6.7.1-2 (effective date no later than 1-7-2012), and 6.7.1-3.

Modifications

• Changes in requirements 3.2.1-1, 4.5.2-1 (effective date no later than 1-2-2012), 4.9.3-4 (effective date no later than 1-4-2012), 3.2.5-1, 5.2.4-2, 5.7.1-2, and 6.2.3-2.
• Comments on attribute subjectAltName:rfc822Name in the certificate profile of certificates under domains Organization Person and Citizen.
• Explanation on attribute subject:serialNumber in the certificate profile of certificates under domain Organization Services.
• change in definition of Profession-related Certificate Holder.

Removals

None.

Editorial

Some editorial changes were made but none have an effect on the informational contents of the document.

Version 3.2 to 3.3

New

• Added requirements 2.2-4, 3.2.5-3, 4.1-1, 4.1-2, 4.5.2-2, 4.10.1-1, 5.2-1 (effective date no later than 1-12-2012), 5.2.5-1 (effective date no later than 1-12-2012), 5.3.1-1, 5.4.3-1, 5.5.1-2, 5.5.2-2, 5.7.1-3, and 5.7.4-1 (effective date no later than 1-12-2012).

Modifications

• Changes in requirements 2.2-4, 3.2.5-3, 4.9.1-1, 4.9.9-1, 4.9.9-3, 5.4.1-1, 5.5.1-1, 5.5.1-2, 5.7.1-1 (effective date no later than 1-10-2012), 5.7.1-2 (effective date no later than 1-10-2012), 6.1.1-4, 6.3.2-2 (effective date no later than 1-10-2012), 6.5.1-3, and 6.7.1-1.
• Explanation on attribute subject:stateOrProvinceName in the certificate profile of certificates under domain Organization Services.
• Explanation on attribute subject:localityName in the certificate profile of certificates under domain Organization Services.
• Comments on attribute subject:commonName in the certificate profile of certificates under domains Organization Services and EV Server.
• Comments on attribute subjectAltName:iPAddress in the certificate profile of certificates under domains Organization Services and EV Server.
• Comments on attribute subjectAltName:dNSName in the certificate profile of certificates under domains Organization Services and EV Server.
• Comments on attribute extKeyUsage in the certificate profile of certificates under domains Organization Services and EV Server.
• Change in definition of Fully-Qualified Domain Name.

Removals

• Requirement 4.4.1-1.

Editorial

Some editorial changes were made but none have an effect on the informational contents of the document.

Version 3.3 to 3.4

New

• Added requirements 2.2-7 (effective date no later than 4 weeks after publication of PoR 3.4), 2.2-5 (effective date no later than 4 weeks after publication of PoR 3.4), 5.2-2 (effective date no later than 4 weeks after publication of PoR 3.4), 5.2.5-2 (effective date no later than 4 weken na datum publicatie PoR 3.4), 5.3.1-1 (effective date no later than 1-7-2013), 5.3.2-1 (effective date no later than 4 weeks after publication of PoR 3.4), 4.9.9-7 (effective date no later than 4 weeks after publication of PoR 3.4), and 4.9.9-8 (effective date no later than 4 weeks after publication of PoR 3.4).

Modifications

• Changes in requirements 4.1-1 (effective date no later than 4 weeks after publication of PoR 3.4), 4.9.9-5 (effective date no later than 4 weeks after publication of PoR 3.4), 5.3.1-1 (effective date no later than 4 weeks after publication of PoR 3.4), and 6.1.1-4 (already effective on 1-10-2012 through high priority change process).
• Explanation and comments on attribute subject:countryName in certificate profile of certificates under domains Organization Person, Organization Services, Citizen, and EV Server (already effective on 1-10-2012 through high priority change process).
• Comments on attribute extKeyUsage in certificate profile of certificates under domains Organization Person, and Autonomous Devices (effective date no later than 4 weeks after publication of PoR 3.4).
• Paragraph 9.12 regarding change procedure.
• Junior Civil-Law Notary included in the list of recognized professions.

Removals

None.

Editorial

• Requirement 5.4.1-1 (effective date no later than 4 weeks after publication of PoR 3.4).

Version 3.4 to 3.5

New

• Requirement 4.9.9-6 (effective date no later than 4 weeks after publication of PoR 3.5).

Modifications

• Requirement 3.2.2-1 (effective date no later than 4 weeks after publication of PoR 3.5).
• Explanation and comments on het attribute QcStatement in certificate profile of certificates under domains Organization Person and Citizen (effective date no later than 4 weeks after publication of PoR 3).
• Comments van het attribute serialNumber in certificate profile of certificates under domains Organization Person, Organization Services, Citizen, Autonomous Devices, and EV Server (effective date no later than 4 weeks after publication of PoR 3.5).
• Removed “Acting Notary” and included “Added Notary”.

Removals

None.

Editorial

• Authorized representative: King’s Commissioner.
• Comments van het attribute subjectAltName:dNSName in certificate profile of certificates under domains Organization Services (effective date no later than 4 weeks after publication of PoR 3.5).
• Comments van het attribute subject:commonName in certificate profile of certificates under domain Organization Services (effective date no later than 4 weeks after publication of PoR 3.5).

Version 3.5 to 3.6

New

• Certify against ETSI TS 102 042 in paragraph 1.1.1 + PTC-BR if applicable (effective date 1 juni 2014).
• Certify against ETSI TS 102 042 in paragraph 1.1.1 + PTC-BR + NetSec if applicable (effective date 1 december 2014).
• Added requirements 6.1.1-4, 6.1.1-5, and 6.1.1-6 (effective date for all 4 weeks after publication of PoR 3.6).

Modifications

• Certify against ETSI EN 319 411-2 (effective date 4 weeks after publication of PoR 3.6).
• Change reference numbers of ETSI EN 319 401 and ETSI 319 411-2 (effective date 4 weeks after publication of PoR 3.6).
• Comments on the attribute subject:commonName in certificate profile of certificates under domain Organization Services (already effective on 16-09-2013 through high priority change process).
• Comments of attribute subjectAltName:dNSName in certificate profile of certificates under domain Organization Services(already effective on 16-09-2013 through high priority change process).
• Explanation of attribute subjectAltname:dNSName in certificate profile of certificates under domain Organization Services (effective date 4 weeks after publication of PoR 3.6).
• Usage of attribute subjectAltname:otherName is no longer mandatory but optional in certificate profile of certificates under domain Organization Services(effective date 4 weeks after publication of PoR 3.6).

Removals

• Remove requirements 6.3.2-2, 9.17-2, 9.17-3, and 9.17-4 due to ban on Code Signing certificates (effective date 4 weeks after publication of PoR 3.6).

Editorial

• Removed double requirement 5.2.5-1 (effective date 4 weeks after publication of PoR 3.6).
• Minor changes in requirements 2.2-5, 4.9.9-3, 5.2, 6.1.1-,1 6.1.1-2, 6.1.1-3, 6.2, 6.2.4-,1 6.3.2-1, and 9.12 (effective date for all 4 weeks after publication of PoR 3.6).
• Minor changes in the CRL profile (effective date 4 weeks after publication of PoR 3.6).
• Minor changes in the certificate profile of certificates under domain Organization Person (effective date 4 weeks after publication of PoR 3.6).

Version 3.6 to 3.7

New

None.

Modifications

• The attribute subjectDirectoryAttributes is no longer critical in the certificate profile for certificates under domain Organization Person (effective date 4 weeks after publication of PoR 3.7).
• Changes in requirements 2.2-5, 2.4-1, 4.1-1, 4.9.1-1, 4.9.3-4, 4.9.7-1, 4.9.9-2, 4.9.9-6, 5.3.2-1, 5.4.1-1, 5.7.4-1, 6.1.1-1, and 7.3-1 because of using in ETSI or BR directly.
• Changes in requirements 6.1.1-2 and 6.2.11-1 (effective date for both 4 weeks after publication of PoR 3.7).

Removals

• Removal of requirements 2.2-4, 2.2-5, 2.2-6, 2.4-1, 3.2.5-3, 4.1-1, 4.5.2-2, 4.9.1-1, 4.9.3-5, 4.9.5-3, 4.9.7-1, 4.9.9-1, 4.9.9-2, 4.9.9-3, 4.9.9-4, 4.9.9-5, 4.9.9-6, 4.9.9-7, 4.9.9-8, 4.10.1-1, 5.2.4-2, 5.3-1, 5.3.1-1, 5.3.2-2, 5.4.1-1, 5.5.1-2, 5.5.2-2, 5.7.1-3, 5.7.1-4, 5.7.4-1, 5.7.4-1, 6.1.1-2, 6.2.11-1, 6.2.11-2, 6.3.2-1, 6.3.2-2, 6.4.1-1, 6.4.1-2, 9.2.1-1, 9.2.1-2, and because already in ETSI or BR (effective date no later than 4 weeks after publication of PoR 3.7).

Editorial

• Minor editorial changes in requirements 4.9.3-4, 5.2.5-1, 6.1.1-5, and 6.2.11-1 (effective date 4 weeks after publication of PoR 3.7).

Version 3.7 to 4.0

New

None.

Modifications

• PoR requirements have been renumbered according to a new naming convention.
• The creation of a document containing the basic and additional requirements.
• Removed all medics in profession list and included reference to a legal register.
• Requirement 2.2-pkio9 expanded applicability to EV Server certificates.
• Requirement 3.3.1-pkio45 expanded applicability to EV Server certificates.
• Requirement 4.9.9-pkio69 expanded applicability to Autonomous Devices certificates.
• Requirement 5.2.4-pkio77 expanded applicability to EV Server certificates.
• Requirement 5.5.1-pkio82 expanded applicability to Organization Person certificates.
• Requirement 6.5.1-pkio116.
• Requirement 4.5.2-pkio52.

Removals

None.

Editorial

None.

Version 4.0 to 4.1

New

• Certification against ETSI TS 102 042 (effective date no later than 4 weeks after publication of PoR 4.1).
• Requirement 3.2.2-pkio147 (effective date no later than 4 weeks after publication of PoR 4.1).
• Requirement 3.2.5-pkio146 (effective date no later than 31-12-2015).

Modifications

• Requirement 3.2.5-pkio35 (effective date no later than 4 weeks after publication of PoR 4.1).
• Requirement 6.3.2-pkio109 (effective date no later than 4 weeks after publication of PoR 4.1).
• Requirement 6.7.1-pkio120 (effective date no later than 01-09-2015).
• Description of the attribute subject:organizationName in the certificate profile for Organization Person certificates (effective date no later than 4 weeks after publication of PoR 4.1).
• Ban on the use of subjectAltName:otherName in certificate profiles of EV Server certificates (effective date no later than 4 weeks after publication of PoR 4.1).
• Changed “Accountants-Administration Officer” to “Accountant-Administration Officer” in profession list.

Removals

• Removal of requirements 3.2.0-pkio12, 3.2.2-pkio15, 3.2.2-pkio17, 3.2.2-pkio18, 3.2.2-pkio19, 3.2.2-pkio20, 3.2.3-pkio23, 3.2.3-pkio25, 3.2.3-pkio28, 4.4.1-pkio50, 4.9.3-pkio59, and 9.6.1-pkio130.

Editorial

• Small editorial changes to requirements 2.2-pkio5, 3.1.3-pkio11,3.2.3-pkio27, 3.2.5-pkio32, 5.3-pkio78, 5.7.4-pkio86, 6.2.5-pkio103, 6.7.1-pkio118, 6.7.1-pkio119, 6.7.1-pkio120, 9.6.1-pkio131, and 9.12.2-pkio136.

Version 4.1 to 4.2

New

• Requirement 6.3.2-pkio148 (effective date no later than 4 weeks after publication of PoR).
• Requirements 7.1-pkio149, 7.1-pkio150, 7.1-pkio151, and 7.1-pkio152 (effective date for all 1 July 2016).

Modifications

• Requirement 7.1-pkio121 (effective date on publication of the PoR).
• Changed use of subjectAltName from “prohibited toegestaan” to “optional” in the certificate profile of certificates under domains G3 Organization Services, Private Organization Services, and Private Server.
• Added OID to Certificate Policies in the certificate profile of certificates under domains G3 Server and EV Server (effective date 1 April 2016).

Removals

• Removed requirement 6.3.2.-pkio109.

Editorial

None.

Version 4.2 to 4.3

New

• Addition of issuer:organizationIdentifier in the certificate profile for certificates under domains G3 Organization Person, G3 Organization Services, G3 Citizens, G3 Autonomous Devices, G3 Server, EV Server, Private Organization Services, Private Server, and Private Person (effective date 1-7-2016).
• New policy identifier and profile modifications for the use of qualified seals in the certificate profile for certificates under domain G3 Organization Services (effective date 1-7-2016).

Modifications

• Changed references from ETSI TS 102 042 to ETSI EN 319 411-1. In addition, updated all reference to paragraph numbers in the relevant ETSI standards.
• Converted all references to ETSI TS 102 176-1 to ETSI TS 119 312 (effective date 4 weeks after publication of the PoR).
• Modified Limitative List of Professions (effective date 29-7-2016).
• Requirement 7.1-pkio150 modified (removed not permitted EKU) (effective date 1-11-2016).
• Modified description with attribute certificatePolicies in the certificate profile for certificates under domains G3 Organization Person, G3 Organization Services, G3 Citizens, G3 Autonomous Devices, G3 Server, EV Server, Private Organization Services, Private Server, and Private Person (effective date 1-7-2016).
• Removal optional use keyAgreement with keyUsage in the certificate profile for certificates in domains G3 Organization Person, G3 Organization Services, G3 Citizens, G3 Autonomous Devices, G3 Server, Private Organization Services, Private Server, and Private Person (effective date no later than 4 weeks after publication of PoR 4.3).
• Mandatory QcStatement in the certificate profile for certificates under domains G3 Organization Person, G3 Organization Services, G3 Citizens, and Private Person (effective date 1-7-2016).
• Use of values in basicConstraints field no longer permitted in the certificate profile for certificates under domains G3 Organization Person, G3 Organization Services, G3 Citizens, G3 Autonomous Devices, G3 Server, EV Server, Private Organization Services, Private Server, and Private Person (effective date 1-7-2016).
• Use of anyExtendedKeyUsage no longer permitted in the certificate profile for certificates under domain G3 Organization Person (effective date 1-11-2016).
• Addition of qualified website certificates in certificate profile of EV Server certificates (effective date 1-7-2016).

Removals:

• Dropped requirement 6.1.2-pkio95 because of duplicate requirement in ETSI EN 319 411-1.

Editorial

• Removed references to G1 (expired) and clarified reference to G3 (domains).

Version 4.3 to 4.4

New

• Added requirement 4.4.3-pkio154 and modified certificate profile accordingly in certificate profiles for certificates under domains G3 Server and EV Server (mandatory use of Certificate Transparency, effective date 1-7-2017).

Modifications

• Modification of requirement 7.1-pkio151; use of EKUs broken down to the different certificate types (effective date 1-2-2017).
• Changed CRL profile to include modified fields in the certificate profile surrounding organizationIdentifier (effective date 1-2-2017).
• Clarification of issuer:organizationIdentifier field in the certificate profile for certificates under domains G3 Organization Person, G3 Organization Services, G3 Citizens, G3 Autonomous Devices, G3 Server, EV Server, Private Organization Services, Private Server, and Private Person (effective date 1-2-2017).
• Tightening of use optional EKUs that conflict with the parent TSP CA certificate in the certificate profile for certificates under domains G3 Organization Person, G3 Organization Person, G3 Citizens, G3 Autonomous Devices, G3 Server, EV Server, Private Organization Services, Private Server, and Private Person (effective date 1-2-2017).
• Prohibit use of QcStatement with authenticity and confidentiality certificate within the domain G3 Citizens (effective date 1-2-2017).

Removals

• Removal of requirement 5.3.2-pkio79 (effective date 1-2-2017).

Editorial

• Changed reference to the CPS (old URL no longer exists) under heading 9.12.
• Changed reference to OCSP profile to correct PoR.
• Replaced CSP (Certificate Service Provider) with TSP (Trust Service Provider) in accordance with eIDAS directive.
• Moved QcStatement from Public to Private Extensions.
• Modified the field extKeyUsage from critical to non-critical (solving conflict between the description and the field value) in the certificate policy of certificates under domain Private Server (effective date immediately after publication of PoR 4.4).

Version 4.4 to 4.5

New

• Added definition of organization name.
• Requirement 2.2-pkio155: Mandatory mention BaselineRequirements domain validation method (effective date 1-10-2017).
• Requirement 2.2-pkio156: mandatory yearly renewal CPS (effective date 1-1-2017).
• Requirement 2.2-pkio157: possibility to offer CPS in English and/or Dutch (effective date 1-10-2017).

Modifications

• Modified limitative list of professions, added article 36a BIG Act.
• Requirement 4.9.9-pkio67 now references RFC 6960 instead of RFC 2560 (effective date 31-12-2017).
• Mandatory English CPS (requirement 2.2-pkio3, effective date 1-10-2017).
• Mandatory use of field nextUpdate in OCSP responses (requirement 4.9.9-pkio71, effective date 1-7-2017).
• Allow/require EKU emailProtection in authenticity and non-repudiation certificates in requirement 7.1-pkio149 (effective date1-4-2017);Change to also cover OCSP responder certificates in OIDs 2.16.528.1.1003.1.2.3.1, 2.16.528.1.1003.1.2.5.1, 2.16.528.1.1003.1.2.5.4, 2.16.528.1.1003.1.2.6.1, 2.16.528.1.1003.1.2.5.6, 2.16.528.1.1003.1.2.7, 2.16.528.1.1003.1.2.8.1, 2.16.528.1.1003.1.2.8.4, and 2.16.528.1.1003.1.2.9.6 (effective date 1-7-2017).

Removals

None.

Editorial

• Changed Certification Service Provider to Trust Service Provider.
• Changed X.509v3 to X.509v2 for CRLs in the CRL profile.
• Modified certificate profile issuer:organizationalIdentifier to issuer:organizationIdentifier.
• Removed references to “Wet Elektronische Handtekeningen” (deprecated).
• Moved QcStatement from public to private extensions.
• Modified URL CPS PA.
• Removed typos from certificate profiles.

Version 4.5 to 4.6

New

• Requirements 4.8-pkio158 and 4.8-pkio159 (effective date 1-9-2017, emergency changes).

Modifications

• Modified limitative list of professions (effective date directly after publication of PoR 4.6).
• Requirement 5.7.1-pkio85 (effective date directly after publication of the PoR).
• Requirement 5.7.1-pkio84 (effective date directly after publication of the PoR).
• Requirement 6.5.1-pkio114 (effective date 1-5-2018).
• Modified reference to ETSI certificate profiles (effective date directly after publication of PoR 4.6).
• Remove exception subject:surname and subject:givenName in the certificate profile for certificates under domains G3 Organization Person and G3 Citizen(effective date directly after publication of PoR 4.6).
• Added subject:organizationIdentifier to fix an omission in the certificate profile for certificates under domain G3 Organization Services (effective date directly after publication of PoR 4.6).
• Corrected subjectAltName:otherName field in the certificate profile for certificates under domains G3 Organization Services, G3 Citizen, Private Organization Services, Private Server, and Private Person (effective date directly after publication of PoR 4.6).
• Prohibition of use of an email address under the fields subjectAltName:rfc822Name and extKeyUsage in certificate profile of certificates under domains G3 Server and EV Server (effective date no later than 4 weeks after publication of PoR 4.6).

Removals

None.

Editorial

None.

Version 4.6 to 4.7

New

• Requirement 2.2-pkio168 (effective date immediately after publication of PoR 4.7).
• Requirement 3.2.3-pkio169 (effective date 4 weeks after publication of PoR 4.7).
• Requirement 3.2.5-pkio160, list of limitative professions (effective date immediately after publication PoR 4.7).
• Requirement 3.2.5-pkio161 (effective date immediately after publication of PoR 4.7).
• Requirement 3.2.5-pkio162 (effective date immediately after publication of PoR 4.7).
• Requirement 3.2.5-pkio170 (effective date immediately after publication of PoR 4.7).
• Requirement 6.1.1-pkio90 (effective date immediately after publication of the PoR 4.7).
• Requirement 7.1-pkio163 (effective date immediately after publication of PoR 4.7).
• Requirement 7.1-pkio164 (effective date immediately after publication of the PoR 4.7).
• Requirement 7.1-pkio165 (effective date immediately after publication of the PoR 4.7).
• Requirement 7.1-pkio171 (effective date immediately after publication of the PoR 4.7).
• Requirement 7.1-pkio172 (effective date 8 weeks after publication of PoR 4.7).
• Requirement 7.1-pkio173 (effective date immediately after publication of PoR 4.7).
• Requirement 7.1-pkio174 (effective date 8 weeks after publication of the PoR 4.7).
• Requirement 7.1-pkio177 (effective date immediately after publication PoR 4.7).

Modifications

• Limitative list of professions transferred to requirement 3.2.5-pkio160 (effective date immediately after publication of the PoR 4.7).
• Requirement 4.8-pkio159 transferred to requirement 8.1-pkio159 (effective date immediately after publication of the PoR).
• Adjustment of reference to ETSI requirements, applicable for requirement 3.3.1-pkio36 and requirement 3.3.2-pkio46 (effective date immediately after publication of the PoR).
• Requirement 6.1.1-pkio90 clarification on generation of certificates (effective date immediately after publication of PoR 4.7).
• Requirement 6.6.1-pkio117 reference to EN 419 211 for QSCDs. (effective date immediately after publication of the PoR).
• Requirement 2.2-pkio9 no longer applicable to certificates under domain EV Server (effective date immediately after publication of PoR 4.7).
• Limitative list of professions updated, “municipal tax bailiff” (latest effective date 4 weeks after publication of PoR 4.7).
• Authentic proof for practicing a recognized profession combined in requirement 3.2.5-pkio29 (effective date immediately after publication PoR 4.7).
• Reference to CWA 14 169 amended to EN 419 211 for QSCDs. This also sets requirements for issuing QSCDs for requirements 6.1.1-pkio88, 6.2.11-pkio104, 6.2.11-pkio105, 6.2.11-pkio106, 6.4.1-pkio112 and 4.9.1-pkio52.
• Description of a number of attributes replaced by reference to requirement 7.1-pkio174 in the certificate profile for certificates under domains G3 Organization Person, G3 Organization Services, G3 Citizen, G3 Autonomous Devices, G3 Server, EV Server, Private Organization Services, Private Server, and Private Person (effective date 8 weeks after publication PoR 4.7).
• Exception provision removed for “any other extKeyUsage associated with the G2 keyusage” from the extKeyUsage field in the certificate profile of certificates under domain G3 Server (effective date immediately after publication of PoR 4).
• Explicitly state that TSP must comply with BRG Section 1.4 in case of certificates under domains G3 Server and EV Server (effective date immediately after publication of PoR 4.7).
• Requirement 4.8-pkio158 transferred to requirement 8.6-pkio158 (effective date immediately after publication of PoR 4.7).
• Declared NetSec integrally applicable for certificates under domains G3 Server and EV Server (effective date immediately after publication of PoR 4.7).

Removals

• Requirement 6.3.2-pkio148 expired and is replaced by requirement 6.3.2-pkio109 (effective date immediately after publication of PoR 4.7).

Editorial

• The reference to the ETSI requirements that deal with the same topic as the PKIoverheid requirement has been moved to an additional tab in the OoA template.

Version 4.7 to 4.8

New

• Requirement 3.2.2-pkio186 for (re)validation of organizational data (effective date immediately after publication PoR 4.8).
• Requirement 4.2-pkio179 on maximum renewal period (effective date November 1, 2019).
• Requirement 5.7.1-pkio181 (effective date immediately after publication of the PoR).
• Requirement 6.3.2-pkio178 on validity of certificates (effective date November 1, 2019).
• Requirement 6.7.1-pkio185 separate requirement for securing web applications (effective date immediately after publication of the PoR).
• Requirement 7.1-pkio182 contains certificatePolicies text which has moved from profile (effective date immediately after publication of PoR 4.8).
• Requirement 8.1-pkio183 on BR self-assessment (effective date immediately after publication of PoR 4.8).
• Requirement 9.17-pkio180 on informing subscribers about revocation periods (effective date August 29, 2019).
• Requirement 9.17-pkio184 reporting on number of certificates issued (effective date immediately after publication of the PoR).

Modifications

• Reference to IETF RFC 2560 changed to IETF RFC 6960 in requirement 4.9.9-pkio69 (effective date immediately after publication of the PoR).
• Change in requirement 6.7.1-pkio118 on patch management arrangements (effective date immediately after publication of the PoR).
• Requirement 5.5.2-pkio83 (effective date immediately after publication of the PoR).
• Change in requirement 7.1-pkio150 to enable usage of constraint (EKU emailProtection) in PoR (effective date immediately after publication PoR 4.8).
• Changes in serial number requirements in requirements 7.1-pkio173 and 7.1-pkio177.
• Removed footnote from subjectAltName:dNSName in certificate profile of certificates under domains G3 Server, EV Server and Server 2020 (effective date immediately after publication of PoR 4.8).
• Removed subject:postalAddress from certificate profile of certificates under domains G3 Server, EV Server and Server 2020 (effective date immediately after publication of PoR 4.8).
• Moved hidden requirement from certificate profile on incorporation of certificatepolicies (OID) in an end-user certificate to new requirement 7.1-pkio182 in certificates under domains G3 Server and EV Server (effective date immediately after publication of PoR 4.8).

Removals

• Requirement 2.2-pkio155 removed (effective date immediately after publication of PoR 4.8).
• Requirement 4.5.2-pkio145 removed (effective date immediately after publication of the PoR 4.8).
• Requirement 6.1.1-pkio91 removed (effective date immediately after publication of PoR 4.8).
• Requirement 9.17-pkio139 removed (effective date immediately after publication PoR 4.8).
• Requirement 9.17-pkio140 removed (effective date immediately after publication PoR 4.8).

Editorial

• Requirement 6.5.1-pkio116 (effective date immediately after publication of the PoR).
• Split requirement 5.7.1-pkio85 rewritten original and new requirement 5.7.1-pkio 181 (effective date immediately after publication of the PoR).
• Requirement 4.9.9-pkio69 reference (effective date immediately after publication of the PoR).
• Requirement 2.2-pkio156 replaced AND by OR (effective date immediately after publication of the PoR).
• Reference to ETSI TS 101 456 7.2.8.d changed to 411-1 in requirement 6.1.2-pkio94 (effective date immediately after publication PoR 4.8).
• Replacement of ETSI TS 102 176 by ETSI TS 119 312 in requirement 6.1.1-pkio91 (effective date immediately after publication of PoR 4.8).
• Changed definition of private key in requirement 4.9.1-pkio52 (effective date immediately after publication PoR 4.8).
• Requirement 4.9.9-pkio68 referenced altered (effective date immediately after publication PoR 4.8).
• Changed reference in requirement 3.2.5-pkio162 (effective date immediately after publication of PoR 4.8).
• Changed reference in requirement 3.2.5-pkio170 (effective date immediately after publication of PoR 4.8).
• Changed definition of private key in requirement 4.9.1-pkio52 (effective date immediately after publication of PoR 4.8).

Version 4.8 to 4.9

New

• Created new additional requirement 2.2-pkio191 (effective date after 01-04-2020).
• Created new additional requirement 4.9.1-pkio192 (effective date 02-17-2020).
• Created new additional requirement 4.9.1-pkio193 (effective date 02-17-2020).
• Requirement 8.1-pkio187, in case the TSP issues or wants to issue non-qualified certificates within PKIoverheid (effective date 02-17-2020).
• Created new additional requirement 8.1-pkio188 (effective date after 02-17-2020).
• Created new additional requirement 8.1-pkio189 (effective date after 02-17-2020).
• Requirement 9.17-pkio190, this requirement only applies if a TSP deploys CAs that are not technically constrained as described in chapter 5.3.1 in the Mozilla Root Store Policy (effective date 02-17-2020).

Modifications

• Change in requirement 3.2.3-pkio169 on email validation (effective date 01-03-2020).
• Change requirements 7.1-pkio171 to comply with Mozilla policy on signature encoding (effective date 01-03-2020).
• Change requirements 6.1.1-pkio89 on allowed signatures (effective date 01-03-2020).
• Requirement 4.9.1-pkio52 no longer required for certificates under domains G3 Organization Person, G3 Organization Services, G3 Citizen, and G3 Autonomous Devices (effective date immediately after publication of PoR 4.9).
• Change the subject:title field in the certificate profile for certificates under domains G3 Organization Person and G3 Autonomous Devices (effective date immediately after publication of PoR 4.9).
• Made the subject:stateOrProvinceName attributes optional in the certificate profile of certificates under domains G3 Server, Private Server, and Private Person (effective date 09-01-2020).

Removals

• Requirement 2.2-pkio7 has been deleted (effective date immediately after publication PoR 4.9).
• Requirement 2.2-pkio8 has been removed (effective date immediately after publication PoR 4.9).
• Requirement 2.2-pkio155 has been deleted (effective date immediately after publication PoR 4.9).
• Requirement 2.2-pkio157 has been removed (effective date immediately after publication PoR 4.9).
• Requirement 4.9.3-pkio54 has been removed (effective date immediately after publication PoR 4.9).
• Requirement 4.9.3-pkio58 has been deleted (effective date immediately after publication PoR 4.9).
• Requirement 4.9.3-pkio60 has been deleted (effective date immediately after publication PoR 4.9).
• Requirement 4.9.5-pkio63 has been removed (effective date immediately after publication PoR 4.9).
• Requirement 4.9.5-pkio64 has been removed (effective date immediately after publication PoR 4.9).
• Requirement 5.2-pkio75 has been removed (effective date immediately after publication PoR 4.9).
• Requirement 6.1.1-pkio87 has been removed (effective date immediately after publication PoR 4.9).
• Requirement 6.1.7-pkio97 has been removed (effective date immediately after publication PoR 4.9).
• Requirement 6.2.3-pkio101 has been removed (effective date immediately after publication PoR 4.9).
• Requirement 6.6.1-pkio117 has been removed (effective date immediately after publication PoR 4.9).
• Requirement 9.12.2-pkio137 has been removed (effective date immediately after publication PoR 4.9).

Editorial

• The attribute subject:stateOrProvinceName becomes optional in the certificate profile of certificates under domain Server 2020 (effective date 09-01-2020).
• Requirement 7.1-pkio171, A TSP MUST limit itself to the signature algorithms as defined in chapter 5.1 (and subsections) of the Mozilla Root Store Policy. The use of RSA-PSS is permitted, but is not recommended (effective date 01-03-2020).

Version 4.9 to 4.10

New

• Added new basic requirement 8.2-pkio199.
• Added new additional requirement 8.4-pkio194.
• Added new additional requirement 8.4-pkio195.
• Added new additional requirement 8.4-pkio196.
• Added new additional requirement 8.4-pkio197.
• Added new additional requirement 8.4-pkio198.
• Added basic requirement 8.2-pkio199.
• Added requirement 8.4-pkio197.
• Added new additional requirement 8.4-pkio200.
• Added basic requirement 9.6.1-pkio127.

Modifications

• Make requirement 9.6.1-pkio127 mandatory for all certificate types.
• Remove references to the Dutch language in requirement 2.2-pkio3.
• Remove specific mandatory verification methods from requirement 3.2.5-pkio146.
• Adopted the usage of the EU Regulated Profession Database in requirement 3.2.5-pkio160.
• Adjusted the maximum number of days for which data for validation of FQDNs may be reused in requirement 3.2.5-pkio170.
• Adjusted the minimal number of SCTs in public TLS certificates from 2 to 3 in requirement 4.4.3-pkio154.
• Removal of user notice from requirement 7.1-pkio182.
• Replace Telecommunications Act with eDIAS in requirement 9.6.1-pkio127.
• Fix of regression error in QcStatement in the certificate profile for certificates under domain G3 Organization Person.
• Change the criterium for the subject:surname attribute from O to V in the certificate profile for certificates under domains G3 Organization Person, G3 Citizen, and Private Person.
• Change the criterium for the subject:givenName attribute from V/O to V in the certificate profile for certificates under domains G3 Organization Person, G3 Citizen, and Private Person.
• Change the criterium for the subject:stateOrProvinceName attribute from V to O in the certificate profile of certificates under domain under domains G3 Server and Server 2020.
• Change the description, explanation, and criterium of the extensions:subjectAltName:otherName attribute in the certificate profile for certificates under domains G3 Organization Person, G3 Organization Services, G3 Citizen, G3 Autonomous Devices, Private Organization Services, Private Server, and Private Person.
• Change extensions:subjectAltName:iPAddress attribute criteria from “O” to “A” for the certificate profile in certificates under domain Private Server.
• Expand the description of the extensions:certificatePolicies field with additional ETSI 319 411 certificate policies in the certificate profile for certificates under domains G3 Organization Person, G3 Organization Service, G3 Citizen, G3 Autonomous Devices, Private Organization Services, and Private Person.
• Change the extensions:certificatePolicies:policyQualifiers:qualifier:userNotice field criteria to “MAY” in the certificate profile for certificates under domains G3 Organization Person, G3 Citizen, G3 Autonomous Devices, Private Organization Services, Private Server, and Private Person.
• Change the description and criteria of the subject:organizationalUnitName attribute in the certificate profile for certificates under domain G3 Organization Services.
• Changes to the subject:organizationIdentifier attribute in the certificate profile for certificates under domain G3 Organization Services.

Removals

• Remove requirement 2.2-pkio6.
• Remove basic requirement 8.1-pkio187.
• Remove additional requirement 8.1-pkio188.
• Remove additional requirement 8.1-pkio189.
• Remove requirement 9.6.1-pkio128.
• Remove requirement 9.6.1-pkio129.
• Remove the extensions:freshestCRL field from the CRL and OCSP profiles.
• Remove the extensions:subjectInfoAccess field from the CRL profile.
• Remove the subject:postalAddress attribute from the certificate profile for certificates under domains G3 Organization Person, G3 Organization Services, G3 Citizen, G3 Autonomous Devices, G3 Server, Private Organization Services, and Private Person.
• Remove the subject:organizationalUnitName attribute from the certificate profile for certificates under domains G3 Organization Person, G3 Citizen, G3 Autonomous Devices, G3 Server, Private Organization Services, Private Person, and Server 2020.
• Remove the extensions:subjectDirectoryAttributes attribute from the certificate profile for certificates under domains G3 Organization Person and Private Person.
• Remove the extensions:subjectAltName:iPAddress field from the certificate profile of certificates under domains G3 Server and Server 2020.
• Remove the extensions:freshestCRL field from the certificate profile for certificates under domains G3 Organization Person, G3 Organization Services, G3 Citizen, G3 Autonomous Devices, G3 Server, Private Organization Services, Private Server, Private Person, and Server 2020.
• Remove the extensions:subjectInfoAccess field from the certificate profile for certificates under domains G3 Organization Person, G3 Organization Services, G3 Citizen, G3 Autonomous Devices, G3 Server, Private Organization Services, Private Server, Private Person, and Server 2020.
• Remove the extensions:biometricInfo field from the certificate profile for certificates under domains G3 Organization Person, G3 Citizen, and Private Person.

Editorial

• Editorial changes in the description and explanation of the extensions:certificatePolicies:policyQualifiers:qualifier:userNotice field (resulting from combining change 450 with change 445.13.) in the certificate profile for certificates under domains G3 Organization Person, G3 Organization Services, G3 Citizen, G3 Autonomous Devices, Private Organization Services, and Private Person.
• Expanded the description of the extensions:basicConstraints field in the certificate profile for certificates under domains G3 Organization Person, G3 Organization Services, G3 Citizen, G3 Autonomous Devices, G3 Server, Private Organization Services, Private Person, and Server 2020.
• Fix a regression error in the description field of the subject:title attribute in the certificate profile for certificates under domain G3 Autonomous Devices.
• Editorial changes to requirement 9.6.1-pkio127.

Version 4.10 to 4.11

New

None.

Modifications

None.

Removals

None.

Editorial

Version bump only.

Version 4.11 to 4.12

New

• Added description of new Certificate types (and corresponding policy OIDs) in section 1.4.1.
• Created requirement 7.1-pkio203 on commonName attribute.
• Created requirement 7.1-pkio204 on commonName attribute.
• Created requirement 7.1-pkio205 on commonName attribute.
• Moved subjectAltName:otherName extension clarifications and clean-ups into new additional requirement 7.1-pkio202.
• New requirement 8.4-pkio201.
• New requirement 9.6.1-pkio229 to indicate CA warranty about S/MIME compliance.
• Created new profiles for G3 2023 and G3 S/MIME in Appendix.

Modifications

• Updated text in section 1.1 to reflect the new and renamed G3 Legacy, G3 2019, G3 2023, and G3 S/MIME PKIoverheid certificate types, and move section upwards in document.
• Updated text in section 1.4.1 with new domain names and SBRG compliance.
• Added definition of Reliable Data Source to Section 1.6.2 “Definitions”.
• Added definition of Sponsor-Validated Certificates to Section 1.6.2 “Definitions”.
• Added SBRG abbreviation to Section 1.6.3.
• Changed applicability list in all requirements to reflect renamed and new certificate types.
• Expanded requirement 2.2-pkio166 to include email validation.
• Expanded applicability of requirements 2.2-pkio166 and 2.2-pkio191 to include new 2023 and S/MIME profiles.
• Expanded requirement 2.2-pkio166 to include email validation.
• Expanded applicability of requirements 2.2-pkio166 and 2.2-pkio191 to include new 2023 and S/MIME profiles.
• Expanded applicability of requirements 3.1.3-pkio11, 3.2.1-pkio13, 3.2.2-pkio4, 3.2.2-pkio14, 3.2.2-pkio16, 3.2.2-pkio144, 3.2.2-pkio186, 3.2.3-pkio21, 3.2.3-pkio22, 3.2.3-pkio24, 3.2.3-pkio26, 3.2.5-pkio29, 3.2.5-pkio30, 3.2.5-pkio31, 3.2.5-pkio32, 3.2.5-pkio33, 3.2.5-pkio34, and 3.2.5-pkio160, to include new 2023 and S/MIME profiles.
• Expanded applicability of requirements 4.1-pkio47, 4.9.1-pkio192, 4.9.3-pkio57, 4.9.7-pkio65, 4.9.9-pkio66, 4.9.9-pkio67, 4.9.9-pkio68, 4.9.9-pkio70, and 4.9.9-pkio71, to include new 2023 and S/MIME profiles.
• Modified requirement 5.4.1-pkio80 to reference the Baseline Requirements from the CA/B Forum.
• Made requirement 5.4.1-pkio80 a basic requirement.
• Updates on audit log retention in requirement 5.4.3-pkio81.
• Expanded applicability of requirements 5.5.1-pkio82 and 5.7.4-pkio86 to include new 2023 and S/MIME profiles.
• Expanded applicability of requirements 6.1.1-pkio88, 6.1.1-pkio92, 6.1.1-pkio93, 6.1.1-pkio153, 6.1.2-pkio94, 6.2.3-pkio99, 6.2.3-pkio100, 6.2.11-pkio104, 6.2.11-pkio106, 6.2.11-pkio125. 6.3.1-pkio108, 6.3.2-pkio109, and 6.3.2-pkio111, to include new 2023 and S/MIME profiles.
• Replaced NCSC reference no longer maintained with an OWASP alternative and fix a broken link in Section 6.7.1.
• Expanded applicability of requirements 7.1-pkio173, 7.1-pkio202, 7.1-pkio203, 7.1-pkio204, 7.1-pkio205, and 7.3-pkio123, to include new 2023 and S/MIME profiles.
• Expanded requirement 7.1-pkio149 to include EKU’s for S/MIME and G3 2023 profiles.
• Made emailProtection EKU no longer mandatory but optional in requirement 7.1-pkio149.
• Consolidated requirements 7.1-pkio50 and 7.1-pkio51 into requirement 7.1-pkio149.
• Retrofitted id-kp-documentSigning EKU in requirement 7.1-pkio151.
• Referenced requirement 7.1-pkio149 in the extendedKeyUsage explanation field of all the different certificate profiles.
• Made requirement 7.1-pkio149 a basic requirement.
• Updated text in requirements 7.1-pkio163 and 7.1-pkio165 with PoR 5.0 retrofit.
• Expanded applicability of requirements 8.4-pkio194, 8.4-pkio195, 8.4-pkio196, and 8.4-pkio200, to include new 2023 and S/MIME profiles.
• Expanded requirements 8.4-pkio194 and 8.4-pkio195 with SRBG requirements.
• Rewrite of requirement 8.4-pkio197 for publicly trusted S/MIME certificates.
• Expanded applicability of requirements 9.6.1-pkio131, 9.6.1-pkio142, 9.8-pkio133, and 9.8-pkio143, to include new 2023 and S/MIME profiles.
• Standardized text on subject:commonName field in all Certificate Profiles by referencing separate requirements.
• Various subjectAltName:otherName extension clarifications and clean-ups in the certificate profile.
• Removed section on commonName naming convention from all Certificate Profiles for natural persons.
• Added SBRG policy OIDs to G3 Legacy profiles.

Removals

• Removed requirement 2.2-pkio166 (duplicates SBRG).
• Removed requirement 3.2.3-pkio169 (replaced by SBRG).
• Removed requirements 7.1-pkio150 and 7.1-pkio151.
• Deleted requirement 7.1-pkio164 since it is no longer in use.

Editorial

• Fixed upper and lower case usage in various ASN.1 field names.
• Added missing reference “section 5.1.2” to the text which describes ECDSA in requirement 6.1.1-pkio89.
• Removed both instances of line “(latest published version applies)” from requirement 8.4-pkio197.
• Retrofitted missing “applicable to” field to requirements 9.6.1-pkio127, 9.6.1-pkio131, 9.6.1-pkio132, and 9.6.1-pkio142.
• Inserted obviously missing “NOT” in description sentence of the issuer:organizationIdentifier field in profile for certificates under the G3 Organization Person domain.
• Clarified the description of the issuer:organizationIdentifier field in all certificate profiles by replacing “issuing CA” with “issuing TSP”, and “TSP certificate” with “TSP issuing certificate”.
• Remove the erroneous Key Agreement bit from the extensions:keyUsage field in the profile for certificates under the Private Server domain.
• Clarify text in subject:organizationalUnitName field in the profile for certificates under the G3 Organization Services domain by changing “name” to “identifier” and “sub-OINs” to “certain sub-OINs”.
• Synchronize the description and explanation text fields of the subject:organizationalUnitName certificate field in the profile for certificates under the Private Organization Services domain with its G3 counterpart.
• Change “natural person” to the obvious “legal person” in the description field of the extensions:certificatePolicies field in the profile for certificates under the G3 Organization Services domain.
• Remove text on EU Qualified certificates from the profile for certificates under the G3 Autonomous Devices domain since those are not issued under this profile.
• Rename G3 profiles to Legacy.
• Rename “OCSP Signing certificates” to “Delegated OCSP Responder certificates”.

Version 4.12 to 5.0

New

• Added definitions of Applicant Representative, Application Software Supplier, Automatic Certificate Management Environment, Critical Security Event, General Data Protection Regulation, High Risk Certificate Request, Legal Entity, Legal Representative, Reliable Data Source, Relying Party, Secure Cryptographic Device, Subject, Subscriber Agreement, Supervisory Authority, Terms and Condition, Terms of Use, User Notice, Verklaring omtrent het gedrag, and Verklaring van geen bezwaar in Section 1.6.2.
• All sub-sections in Section 7 (complete re-write).
• Added new requirement text in Section 2.2 (consolidating and clarifying requirements 2.2-pkio3, 2.2-pkio5, 2.2-pkio156, 2.2-pkio166, 2.2-pkio168, and 2.2-pkio191).
• Added new requirement text in Section 3.2.2.1 (merge and rewrite of requirements 3.2.2-pkio4, 3.2.2-pkio14, 3.2.2-pkio16, and 3.2.2-pkio144).
• Added new requirement text in Section 3.2.2.4 (merge and rewrite of requirements 3.2.5-pkio162 and 3.2.5-pkio170).
• Added new requirement text in Section 3.2.5 (merge and rewrite of 3.2.5-pkio29, 3.2.5-pkio30, 3.2.5-pkio31).
• Added new requirement text in Section 3.2.3 (added operational validity of verified identity information).
• Added new requirement text in Section 4.9.9 (consolidates and clarify requirements 4.9.9-pkio67, 4.9.9-pkio68, 4.9.9-pkio69, 4.9.9-pkio70, 4.9.9-pkio71, and 4.9.9-pkio152).
• Added new requirement text in Section 4.9.10 on on-line revocation checking requirements.
• Added new requirement text in Section 5 (includes simplified version of requirement 5.2-pkio74).
• Added new requirement text in Section 6.2.7 (merge of requirements 6.2.11-pkio104 and 6.2.11-pkio125).
• Added new requirement text in Section 6.2.11 (merge of requirements 6.2.11-pkio105 and 6.2.11-pkio106).
• Added new requirement text in Section 6.3.2.1 (merge of requirements 6.3.2-pkio109, 6.3.2-pkio110, 6.3.2-pkio111, and 6.3.2-pkio178).
• Added new requirement text in Section 6.3.2.2 (merge of requirements 3.3.1-pkio36, 6.3.2-pkio109, 6.3.2-pkio111, and 6.3.2-pkio178).
• Added new requirement text in Section 6.5.1 (rewritten version of requirements 6.7.1-pkio118, 6.7-pkio119, 6.7.1-pkio120, and 6.7.1-pkio120).
• Added new Sections 8.4.1 “Requirements covered by assessment”, 8.4.2 “Changes in requirements covered by assessment”, 8.4.3 “Parties covered by assessment”, and 8.4.4 “Assessment reports”.
• Added new requirement text in Section 8.4.1 (combines all previous 8.4 requirements).
• Added new requirement text in Section 8.4.2 (rewritten from former requirement 8.1-pkio183).
• Added new requirement text in Section 8.4.3 (rewritten part of former requirement 6.5.1-pkio115).
• Added new requirement text in Section 8.4.4 (separated from former requirement 8.1-pkio159).
• Added new requirement text in Section 8.6 (rewritten part of former requirement 6.5.1-pkio115).
• Added new Sections 9.6.1.1 “CA Representation for third parties” and 9.6.1.2 “S/MIME warranties”.
• Added new requirement text in Section 9.6.1.1 (combination of requirements 9.6.1-pkio127 and 9.6.1-pkio142).
• Added new requirement text in Section 9.6.1.2 (moved from 9.6.1-pkio129).
• Added new requirement text in Section 9.8 (combination of requirements 9.6.1-pkio131, 9.6.1-pkio132, 9.8-pkio133, 9.8-pkio135, and 9.8-pkio143).
• Added new text in Section 9.12 (rewritten in comments).
• Added new text in Section 9.14 (rewritten in comments).
• Added new Sections 9.17.1 “Reporting on issued certificates” and 9.17.2 “CA Operational Changes”.

Modifications

• Updated definitions of Applicant, Signature Creation Device, and Subscriber in Section 1.6.2.
• Added GDPR, SA, VGB, and VOG abbreviations to Section 1.6.3.
• Expanded abbreviation SCD in Section 1.6.3
• Added requirement for SHA256 fingerprints in CPS in Section 2.2.
• Clarified text in Section 3.1.1.
• Added comment to Section 3.1.3.
• Modified Section 3.2.1 to clarify what implies possession of private key.
• Added new certificate types to Section 3.2.1 due to SBRG inclusion.
• Added operational validity of verified identity information in Section 3.2.
• Added missing sub-sections under Section 3.2.2.
• Simplified Sections 3.3.1 and 3.3.2 (duplicate ETSI requirements removed).
• Clarified Section 4.5.2.
• Clarified and expand requirement in Section 4.9.1 (consolidates requirements 4.9.1-pkio52 and 4.9.1-pkio192).
• Simplified requirement in Section 4.9.2.
• Added a comment to Section 4.9.13.
• Modified text in Section 4.10.2 (pointer to BR).
• Added comment to Section 5.2.
• Added requirement in Section 5.3 on certificate of conduct.
• Rewritten requirement text in Section 5.7.1 (reference BR and clarification of requirement 5.7.1-pkio181).
• Simplified and clarified text in Section 6.1.1.3 (merge with requirement 6.1.1-pkio91).
• Simplified and clarified text in Section 6.1.2 (containing parts of requirement 6.1.1-pkio89).
• Simplified and modernized text in Section 6.1.5 (reference Section 6.1.5 in the BR).
• Clarified and future-proofed text in Section 6.2.3 (S/MIME proofing and merge with requirements 6.2.3-pkio99 and 6.2.3-pkio100).
• Modified requirement text in section 6.3.1 (depend on EKUs instead of domain certificates).
• Added time frame to Section 8.6.
• Add CSPRNG abbreviation to Section 1.6.3 “Abbreviations”.

Removals

• Removed requirements in Section 2.1-pkio1 (overlaps with ETSI EN 319 411-1 DIS-6.1-07A and DIS-6.1-04).
• Removed requirements 2.2-pkio3, 2.2-pkio5, 2.2-pkio156, 2.2-pkio166, 2.2-pkio168, and 2.2-pkio191 (consolidated and clarified in new Section 2.2 requirement).
• Removed requirement 3.2.2-pkio4 (merged in new requirement 3.2.2-pkio206).
• Removed requirement 3.2.2-pkio14 (merged in new requirement 3.2.2-pkio206).
• Removed requirement 3.2.2-pkio16 (merged in new requirement 3.2.2-pkio206).
• Removed requirement 3.2.2-pkio144 (merged in new requirement 3.2.2-pkio206).
• Removed requirement 3.2.2-pkio186 (moved to comment sections in new requirements).
• Removed requirement 3.2.3-pkio169 (duplicates S/MIME BR).
• Removed requirements 3.2.3-pkio21, 3.2.3-pkio22, 3.2.3-pkio24, 3.2.3-pkio26, and 3.2.3-pkio27 (removed due to redundancy with ETSI 319 411-1 Section 6.2.2).
• Removed requirements 3.2.5-pkio29, 3.2.5-pkio30, and 3.2.5-pkio31 (merged in new requirement under Section 3.2.5).
• Removed requirements 3.2.5-pkio32, 3.2.5-pkio33, and 3.2.5-pkio34 (merged in new requirement under Section 4.1.1).
• Removed requirements 3.2.5-pkio162 and 3.2.5-pkio170 (merged in new requirement under Section 3.2.2).
• Removed requirement 3.3.1-pkio36 (merged into Section 6.3.2.2).
• Removed requirement 3.3.2-pkio46 (identical to ETSI EN 319 411-1 GEN-6.3.6-10).
• Removed requirement 4.1-pkio47 (merged with 3.2.5-pkio32, 3.2.5-pkio33, and 3.2.5-pkio34, and subsequently split up requirements under both Sections 4.1.1 and 4.1.2).
• Removed requirement 4.2-pkio179 (Server 2020 no longer applicable).
• Removed requirement 4.4.1-pkio49 (redundant with ETSI 319 411-1 OVR-6.3.4-01).
• Removed requirement 4.4.3-pkio154 (publicly-trusted TLS certificates are no longer issued within PKIoverheid).
• Removed requirements 4.9.1-pkio52 and 4.9.1-pkio192 (consolidated in requirement in Section 4.9.1).
• Removed requirements 4.9.3-pkio55 (should be part of Section 4.10.2), 4.9.3-pkio56 (reiterates ETSI EN 319 411-1 REV-6.4.5-09) and 4.9.3-pkio57 (should be part of Section 4.10).
• Removed requirement 4.9.5-pkio61 (maximum delay is described in ETSI EN 319 411-1 REV-6.2.4-03A).
• Removed requirement 4.9.7-pkio65 (issuing frequency is described in ETSI EN 319 411-1 CSS-6.3.9-05).
• Removed requirement 4.9.9-pkio66 (availability is described in ETSI EN 319 411-1 CSS-6.3.10-10).
• Removed requirements 4.9.9-pkio67, 4.9.9-pkio68, 4.9.9-pkio69, 4.9.9-pkio70, 4.9.9-pkio71, and 4.9.9-pkio152 (consolidated in new requirement text in Section 4.9.9).
• Removed requirement 5.2-pkio74 (moved to Section 5).
• Removed requirements 5.2.4-pkio76 and 5.2.4-pkio77 (are described in NetSec Section 2 and also OVR-6.4.3-01 and OVR-6.5.5-01 in ETSI EN 319 411-1).
• Removed requirement 5.3-pkio78 (poorly re-iterates GDPR which is already law).
• Removed requirement 5.5.1-pkio82 (is described in OVR-6.4.6-01 in ETSI EN 319 411-1).
• Removed requirement 5.7.1-pkio85 (is already part of convenant and largely overlaps with Section 5.7.1).
• Removed requirement 5.7.4-pkio86 (part of new text in Section 5.7.1).
• Removed requirement 6.1.1-pkio88 (QSCDs no longer mandatory for non-Qualified certificates; QSCDs for Qualified certificates are described in ETSI 319 411-2).
• Removed requirement 6.1.1-pkio89 (duplicates Section 7.1.3, partly merged with Section 6.1.2).
• Removed requirement 6.1.1-pkio90 (publicly-trusted TLS certificates are no longer issued within PKIoverheid).
• Removed requirement 6.1.1-pkio92 (code signing is not possible due to technical constraints).
• Removed requirement 6.1.1-pkio93 (adds very little to ETSI EN 319 411-1).
• Removed requirement 6.1.1-pkio153 (merged with new text in Section 6.1.1.3).
• Removed requirement 6.1.2-pkio94 (is described in ETSI EN 319 411-1 SDP 6.3.3-09).
• Removed requirements 6.2.3-pkio99 and 6.2.3-pkio100 (merged in Section 6.2.3).
• Removed requirements 6.2.11-pkio104 and 6.2.11-pkio125 (merged in Section 6.2.7).
• Removed requirements 6.2.11-pkio105 and 6.2.11-pkio106 (merged in Section 6.2.11).
• Removed requirement 6.2.11-pkio107 (not enforceable).
• Removed requirements 6.3.2-pkio109, 6.3.2-pkio111, and 6.3.2-pkio178 (merged into 6.3.2.1 and 6.3.2.2).
• Removed requirement 6.3.2-pkio110 (merged into requirement 6.3.2.1).
• Removed requirements 6.4.1-pkio112 and 6.4.1-pkio113 (already part of the evaluation schemes mentioned in Section 6.2.11).
• Removed requirements 6.5.1-pkio114 and 6.5.1-pkio116 (no real added value to NetSec mandated in Section 6.7).
• Removed requirement 6.5.1-pkio115 (rewritten partly in new requirement text in Section 8.6).
• Removed requirements 6.7-pkio119, 6.7.1-pkio118, 6.7.1-pkio120, and 6.7.1-pkio185 (merged in Section 6.5.1 and already present in NetSec).
• Removed requirement 7.1-pkio121 (merged in Section 7.1).
• Removed requirement 7.1-pkio149 (merged in Section 7.1.2.3.15).
• Removed requirements 7.1-pkio163, 7.1-pkio165 (merged in Section 7.1.4.2.1).
• Removed requirement 7.1-pkio171 (merged in Section 7.1.3.2).
• Removed requirement 7.1-pkio172 (merged in Section 7.1.2.3.16).
• Removed requirements 7.1-pkio173, 7.1-pkio177 (merged in Section 7.1.4.2.2.3).
• Removed requirement 7.1-pkio174 (merged in Section 7.1.4.1).
• Removed requirement 7.1-pkio182 (merged in Section 7.1.6.4).
• Removed requirement 7.1-pkio202 (merged in Section 7.1.4.2.1.3).
• Removed requirements 7.1-pkio203, 7.1-pkio204, 7.1-pkio205 (merged in Section 7.1.4.2.2.1).
• Removed requirement 7.2-pkio122 (merged in Section 7.2).
• Removed requirement 7.3-pkio123 (merged in Section 7.3).
• Removed requirement 8.1-pkio183 (rewritten in Section 8.4.2).
• Removed requirements 8.4-pkio194, 8.4-pkio195, 8.4-pkio196, 8.4-pkio197, 8.4-pkio198, 8.4-pkio200, and 8.4-pkio201 (combined in Section 8.4.1).
• Removed requirement 8.6-pkio158 (rewritten in Section 8.4.2).
• Removed requirements 9.6.1-pkio127 and 9.6.1-pkio142 (combined in Section 9.6.1.1).
• Removed requirement 9.6.1-pkio129 (moved to Section 9.6.1.2).
• Removed requirements 9.6.1-pkio131, 9.6.1-pkio132, 9.8-pkio133, 9.8-pkio135, and 9.8-pkio143 (merged in Section 9.8).
• Removed requirement 9.17-pkio180 (no longer relevant).

Editorial

• Removed all references to requirement numbers.
• Removed all applicability lists.
• Added new Sections 3.2.5.1 “Legal representation”, 3.2.5.2 “Delegated representation”, 3.2.5.3 “Regulated professions”, and 3.2.5.3 “High-risk certificate request”.
• Added new Sections 5.7.1.1 “Incident Response and Disaster Recovery Plan”, 5.7.1.2 “Communication”, and 5.7.1.3 “Vulnerability Management”.
• Added new Sections 6.3.2.1 “Certificate operational periods” and 6.3.2.2 “Key pair usage periods”.
• Removed Section 6.7.1 (duplicate of Section 6.7).
• Modernized text in Sections 9.2, 9.5, 9.13, and 9.17.
• Removed references to G3 Server, EV and Server2020 certificates from section 1 (deprecated)
• Removed all references to requirement numbers.
• Removed all applicability lists.

1.2.2 Relevant dates

1.3 PKI participants

1.3.1 Certification authorities

In this document the distinction is made between the term Certification Authority (CA) and Trust Service Provider. In international usage, “CA” is an umbrella term that refers to all entities authorized to issue, manage, revoke, and renew certificates. This can apply to the actual CA certificate as well as the organization. In this CP, the organization which holds a CA is referred to as a TSP. The term CA is used to refer to the infrastructure and keymaterial from which a TSP issues and signs certificates.

All TSPs issuing PKIo certificates are mentioned in the list below:

• Digidentity:
  • G3 Legacy Organization Person certificates (previously 3a)
  • G3 Legacy Organization Services certificates (previously 3b)
  • G3 Legacy Citizen certificates (previously 3c)
  • Private Organization Services certificates (previously 3g)
  • Private Server certificates (previously 3h)
• KPN:
  • G3 Legacy Organization Person certificates (previously 3a)
  • G3 Legacy Organization Services certificates (previously 3b)
  • Private Organization Services certificates (previously 3g)
  • Private Server certificates (previously 3h)
• QuoVadis:
  • G3 Organization Person certificates (previously 3a)
  • G3 Organization Services certificates (previously 3b)
  • G3 Citizen certificates (previously 3c)
  • Private Person certificates (previously 3i)
  • Private Organization Services certificates (previously 3g)
  • Private Server certificates (previously 3h)
• Cleverbase:
  • G3 Legacy Citizen certificates (previously 3c)
• Ministerie van Defensie:
  • G3 Legacy Organization Person certificates (previously 3a)
• Ministerie van Infrastructuur en Waterstaat:
  • G3 Legacy Organization Person certificates (previously 3a)
  • G3 Legacy Organization Services certificates (previously 3b)
  • G3 2019 Autonomous Devices certificates (previously 3d)
• CIBG:
  • G3 Legacy Organization Person certificates (previously 3a)
  • G3 Legacy Organization Services certificates (previously 3b)
  • Private Server certificates (previously 3h)

An up-to-date list of all PKIo CA certificates is published on https://cert.pkioverheid.nl.

1.3.2 Registration authorities

Registration Authorities (RAs) are entities that approve and authenticate requests to obtain, renew, or revoke certificates. RA tasks within PKIoverheid are as follows:

• Identify and authenticate subscribers,
• Verify that subscribers are authorised to request or revoke certificates, and
• Approving individuals, entities, and/or devices that are to be included in a certificate.

After performing the tasks listed above they will authorize and/or request a TSP to issue, renew, or revoke a certificate.

1.3.3 Subscribers

Subscribers within the PKIoverheid hierarchy are defined as organizations or individuals (working for organizations) to whom a TSP has issued (a) PKIoverheid (TRIAL) certificate(s). Prior to issuance of the first certificate the subscriber must agree to a Subscriber agreement supplied by the TSP. Requirements for this subscriber agreement are listed in relevant sections of this CP.

1.3.4 Relying parties

No stipulation.

1.3.5 Other participants

No stipulation.

1.4 Certificate usage

1.4.1 Appropriate certificate uses

The use of certificates issued under this CP relates to communication of certificate holders who act on behalf of the subscriber.

• G3 Legacy Organization Person certificates (previously 3a):
  • [OID 2.16.528.1.1003.1.2.5.1]: Authenticity certificates, that are issued under this CP, can be used to reliably identify and authenticate persons, organizations and resources electronically. This concerns both the mutual identification of people and identification between people and computerized devices. Under this OID OCSP responder certificates may be issued for use within the domain Organisation Person. Said certificates can be used to sign OCSP responses for use in the verification of the validity of the end user certificate. These certificates MAY be used for S/MIME signing. If S/MIME capable, these certificates adhere to the latest version of the SBRGs.
  • [OID 2.16.528.1.1003.1.2.5.2]: Signature certificates, that are issued under this CP, can be used to verify electronic signatures, that have “the same legal consequences as a handwritten signature”, as stated in article 15a, first and second paragraphs, in Title 1 of Book 3 of the Dutch Civil Code (Burgerlijk Wetboek) under section 1A and are qualified certificates as referred to in article 1.1, paragraph ss of the Telecommunications Act (Telecomwet). These certificates MAY be used for S/MIME signing. If S/MIME capable, these certificates adhere to the latest version of the SBRGs.
  • [OID 2.16.528.1.1003.1.2.5.3]: Confidentiality certificates, that are issued under this CP, can be used to protect the confidentiality of data that is exchanged and/or stored in an electronic form. This concerns both the mutual exchange between people and exchange between people and computerized devices. These certificates MAY be used for S/MIME encryption. If S/MIME capable, these certificates adhere to the latest version of the SBRGs.
• G3 Legacy Organization Services certificates (previously 3b):
  • [OID 2.16.528.1.1003.1.2.5.4]: Authenticity certificates, issued under this CP, can be used to identify and authenticate, by electronic means, the service that is part of the organizational entity, that is responsible for the relevant service. Issuance of code signing certificates by means of which the integrity and authenticity of software can be safeguarded by a digital signature being placed are NOT allowed under this CP. Under this OID OCSP responder certificates may be issued for use within the domain Organisation Services. Said certificates can be used to sign OCSP responses for use in the verification of the validity of the end user certificate. These certificates MAY be used for S/MIME signing. If S/MIME capable, these certificates adhere to the latest version of the SBRGs.
  • [OID 2.16.528.1.1003.1.2.5.5]: Confidentiality certificates, issued under this CP, can be used to protect the confidentiality of data that is exchanged and/or stored in an electronic format. These certificates MAY be used for S/MIME encryption. If S/MIME capable, these certificates adhere to the latest version of the SBRGs.
  • [OID 2.16.528.1.1003.1.2.5.7]: Seal certificates, issued under this CP, can be used to verify electronic seals. These certificates MAY be used for S/MIME signing. If S/MIME capable, these certificates adhere to the latest version of the SBRGs.
• G3 Legacy Citizen certificates (previously 3c):
  • [OID 2.16.528.1.1003.1.2.3.1]: Authenticity certificates, that are issued under this CP, can be used for reliable electronic identification and authentication of persons. This concerns both the mutual identification of people and identification between people and computerized devices. Authenticity certificates that are issued under this CP cannot be used to identify people in cases where the law requires that the identity of persons may only be established using the document referred to in the Compulsory Identification Act (Wet op de identificatieplicht). Under this OID OCSP responder certificates may be issued for use within the domain Citizen. Said certificates can be used to sign OCSP responses for use in the verification of the validity of the end user certificate. These certificates MAY be used for S/MIME signing. If S/MIME capable, these certificates adhere to the latest version of the SBRGs.
  • [OID 2.16.528.1.1003.1.2.3.2]: Signature certificates, that are issued under this CP, can be used to verify electronic signatures, that have “the same legal consequences as a handwritten signature”, as specified in article 15a, first and second paragraphs, in Title 1 of Book 3 of the Civil Code (Burgerlijk Wetboek) under section 1A and are qualified certificates as referred to in article 1.1, paragraph ss of the Telecommunications Act (Telecomwet).These certificates MAY be used for S/MIME signing. If S/MIME capable, these certificates adhere to the latest version of the SBRGs.
  • [OID 2.16.528.1.1003.1.2.3.3]: Confidentiality certificates, issued under this CP, can be used to protect the confidentiality of data that is exchanged and/or stored in electronic form. This concerns both the mutual exchange between people and exchange between people and computerized devices. These certificates MAY be used for S/MIME encryption. If S/MIME capable, these certificates adhere to the latest version of the SBRGs.
• G3 2019 Autonomous Devices certificates (previously 3d):
  • [OID 2.16.528.1.1003.1.2.6.1]: Authenticity certificates, which are issued under this CP, can be used for electronically reliably identifying and authenticating the Autonomous Device and its certified operation. Under this OID OCSP responder certificates may be issued for use within the domain Autonomous Devices. Said certificates can be used to sign OCSP responses for use in the verification of the validity of the end user certificate.
  • [OID 2.16.528.1.1003.1.2.6.2]: Confidentiality certificates, issued under this CP, can be used to protect the confidentiality of data that is exchanged with the Autonomous Device and/or stored in that in its electronic form.
  • [OID 2.16.528.1.1003.1.2.6.3]: Combination certificates that are issued under this CP can be used to safeguard a connection between a specific client and an Autonomous Device.
• G3 2023 Organization Person certificates:
  • [OID 2.16.528.1.1003.1.2.5.10]: Authenticity certificates, that are issued under this CP, can be used to reliably identify and authenticate persons, organizations and resources electronically. This concerns both the mutual identification of people and identification between people and computerized devices. These certificates can not be used for S/MIME.
  • [OID 2.16.528.1.1003.1.2.5.11]: Signature certificates, that are issued under this CP, can be used to verify electronic signatures, that have “the same legal consequences as a handwritten signature”, as stated in article 15a, first and second paragraphs, in Title 1 of Book 3 of the Dutch Civil Code (Burgerlijk Wetboek) under section 1A and are qualified certificates as referred to in article 1.1, paragraph ss of the Telecommunications Act (Telecomwet). These certificates can not be used for S/MIME.
  • [OID 2.16.528.1.1003.1.2.5.12]: Confidentiality certificates, that are issued under this CP, can be used to protect the confidentiality of data that is exchanged and/or stored in an electronic form. This concerns both the mutual exchange between people and exchange between people and computerized devices. These certificates can not be used for S/MIME.
• G3 2023 Organization Services certificates:
  • [OID 2.16.528.1.1003.1.2.5.13]: Authenticity certificates, issued under this CP, can be used to identify and authenticate, by electronic means, the service that is part of the organizational entity, that is responsible for the relevant service. Issuance of code signing certificates by means of which the integrity and authenticity of software can be safeguarded by a digital signature being placed are NOT allowed under this CP. These certificates can not be used for S/MIME.
  • [OID 2.16.528.1.1003.1.2.5.14]: Confidentiality certificates, issued under this CP, can be used to protect the confidentiality of data that is exchanged and/or stored in an electronic format. These certificates can not be used for S/MIME.
  • [OID 2.16.528.1.1003.1.2.5.15]: Seal certificates, issued under this CP, can be used to verify electronic seals. These certificates can not be used for S/MIME.
• G3 2023 Citizen certificates:
  • [OID 2.16.528.1.1003.1.2.3.4]: Authenticity certificates, that are issued under this CP, can be used for reliable electronic identification and authentication of persons. This concerns both the mutual identification of people and identification between people and computerized devices. Authenticity certificates that are issued under this CP cannot be used to identify people in cases where the law requires that the identity of persons may only be established using the document referred to in the Compulsory Identification Act (Wet op de identificatieplicht). These certificates can not be used for S/MIME.
  • [OID 2.16.528.1.1003.1.2.3.5]: Signature certificates, that are issued under this CP, can be used to verify electronic signatures, that have “the same legal consequences as a handwritten signature”, as specified in article 15a, first and second paragraphs, in Title 1 of Book 3 of the Civil Code (Burgerlijk Wetboek) under section 1A and are qualified certificates as referred to in article 1.1, paragraph ss of the Telecommunications Act (Telecomwet). These certificates can not be used for S/MIME.
  • [OID 2.16.528.1.1003.1.2.3.6]: Confidentiality certificates, issued under this CP, can be used to protect the confidentiality of data that is exchanged and/or stored in electronic form. This concerns both the mutual exchange between people and exchange between people and computerized devices. These certificates can not be used for S/MIME.
• G3 2023 S/MIME certificates:
  • [ OID 2.16.528.1.1003.1.2.10.9]: Individual-validated S/MIME Certificates, issued under this CP, can be used to sign and encrypt email messages by Individuals (Natural Persons) in combination wih a Legal Entity. These certificates are based on (and adhere to) the latest version of the SBRG S/MIME Sponsor-validated – Strict profile, ETSI EN 319 411-1 NCP and ETSI TS 119 411-6.
  • [ OID 2.16.528.1.1003.1.2.11.9]: Organization-validated S/MIME Certificates, issued under this CP, can be used to sign and encrypt email messages by Legal Entities. These certificates are based on (and adhere to) the latest version of the SBRG S/MIME Organization-validated – Strict profile, ETSI EN 319 411-1 NCP and ETSI TS 119 411-6.
  • [ OID 2.16.528.1.1003.1.2.12.9]: Sponsor-validated S/MIME Certificates, issued under this CP, can be used to sign and encrypt email messages by Individuals (Natural Persons). These certificates are based on (and adhere to) the latest version of the SBRG S/MIME Individual-validated – Strict profile, ETSI EN 319 411-1 NCP and ETSI TS 119 411-6.
• Private Organization Services certificates (previously 3g):
  • [OID 2.16.528.1.1003.1.2.8.4]: Authenticity certificates, issued under this CP, can be used to identify and authenticate, by electronic means, the service that is part of the organizational entity, which is responsible for the relevant service. Issuance of code signing certificates by means of which the integrity and authenticity of software can be safeguarded by a digital signature being placed are NOT allowed under this CP. Under this OID OCSP responder certificates may be issued for use within the domain Private Services. Said certificates can be used to sign OCSP responses for use in the verification of the validity of the end user certificate. These certificates can optionally be used for S/MIME signing, depending on the TSP
  • [OID 2.16.528.1.1003.1.2.8.5]: Confidentiality certificates, issued under this CP, can be used to protect the confidentiality of data that is exchanged and/or stored in an electronic format. These certificates can optionally be used for S/MIME encryption, depending on the TSP
• Private Server certificates (previously 3h):
  • [OID 2.16.528.1.1003.1.2.8.6]: Server certificates that are issued under this CP, can be used to secure a connection between a specific client and a server that is part of the organizational entity listed as the subscriber in the relevant certificate. Under this OID OCSP responder certificates may be issued for use within the domain Private Services. Said certificates can be used to sign OCSP responses for use in the verification of the validity of the end user certificate.
• Private Person certificates (previously 3i):
  • [OID 2.16.528.1.1003.1.2.8.1]: Authenticity certificates, which are issued under this CP, can be used to reliably identify and authenticate persons, organizations and resources electronically. This concerns both the mutual identification of people and identification between people and computerized devices. Under this OID OCSP responder certificates may be issued for use within the domain Private Persons. Said certificates can be used to sign OCSP responses for use in the verification of the validity of the end user certificate. These certificates can optionally be used for S/MIME signing, depending on the TSP
  • [OID 2.16.528.1.1003.1.2.8.2]: Signature certificates, which are issued under this CP, can be used to verify electronic signatures, that have “the same legal consequences as a handwritten signature”, as stated in article 15a, first and second paragraphs, in Title 1 of Book 3 of the Dutch Civil Code (Burgerlijk Wetboek) under section 1A and are qualified certificates as referred to in article 1.1, paragraph ss of the Telecommunications Act (Telecomwet). These certificates can optionally be used for S/MIME signing, depending on the TSP
  • [OID 2.16.528.1.1003.1.2.8.3]: Confidentiality certificates, which are issued under this CP, can be used to protect the confidentiality of data that is exchanged and/or stored in an electronic form. This concerns both the mutual exchange between people and exchange between people and computerized devices. These certificates can optionally be used for S/MIME encryption, depending on the TSP
• OCSP certificates:
  • [OID 2.16.528.1.1003.1.2.5.8]: Under this OID OCSP responder certificates may be issued for use within the different 2023 domains. Said certificates can be used to sign OCSP responses for use in the verification of the validity of the end user certificate.

1.4.2 Prohibited certificate uses

Refer to the individual requirements in this Programme of Requirements.

1.5 Policy administration

1.5.1 Organization administering the document

The Ministry of Interior and Kingdom Relations (BZK) is responsible for this CPS. BZK has delegated this responsibility to Logius, including approval of changes of this document.

1.5.2 Contact person

Policy Authority PKIoverheid
Wilhelmina van Pruisenweg 52
Postbus 96810
2509 JE DEN HAAG
https://www.logius.nl/pkioverheid
servicecentrum@logius.nl

1.5.3 Person determining CPS suitability for the policy

The Policy Authority PKIoverheid (PA) determines the suitability of CPSs published as a result of this CP.

1.5.4 CP approval procedures

The PA PKIoverheid reserves the right to amend this CP. Changes are applicable from the date that is listed in section 1.2.2. Relevant dates. The management of Logius is responsible for following the procedures as listed in section 9.12 Amendments and final approval of this CP.

1.6 Definitions and acronyms

1.6.1 Conventions

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in these Requirements MUST be interpreted in accordance with RFC 2119.

1.6.2 Definitions

A-Label: The ASCII-compatible encoding of a valid Internationalized Domain Names in Applications (IDNA) label. A-labels consist of the prefix xn-- followed by a valid Punycode string.

Abstract Syntax Notation One (ASN.1): A language for describing structured information; typically, information intended to be conveyed across some interface or communication medium.

Accreditation: Procedure whereby the organization that has authority issues formal recognition that an entity is competent to undertake specific tasks.

Affiliate: A corporation, partnership, joint venture or other entity controlling, controlled by, or under common control with another entity, or an agency, department, political subdivision, or any entity operating under the direct control of a Government Entity.

Algorithm: A collection of instructions that should be carried out step-by-step in order to carry out a calculation process or resolve a specific type of problem.

American Standard Code for Information Interchange (ASCII): ASCII is the most common character encoding format for text data in computers and on the internet.

Applicant: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual certificate request.

Applicant Representative: A Natural Person or human sponsor who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant:

1. who signs and submits, or approves a Certificate Request on behalf of the Applicant;
2. who signs and submits a Subscriber Agreement on behalf of the Applicant; and/or
3. who acknowledges the Terms of Use on behalf of the Applicant when the Applicant is an Affiliate of the TSP or is the TSP.

Application Programming Interface - API: A formalized collection of invocations and routines that are carried about by an application to utilise supporting services (for example a network).

In relation to PKI these are invocations from applications that use cryptographic transactions (encryptions, registrations, etc.).

Application Software Supplier: A supplier of Internet browser software or other relying‐party application software that displays or uses Certificates and incorporates Root Certificates.

Asymmetric key pair: A public and private key within public key cryptographics that are connected to each other mathematically so that the public key and the private key are each other’s counterpart. If one key is used for encryption, the other has to be used for decryption and vice versa.

Attestation: A letter attesting that Subject Information is correct written by an accountant, lawyer, government official, or other reliable third party customarily relied upon for such information.

Attribute Authority – AA (NL: Attribuut Autoriteit): An authority that awards privileges by signing and issuing attribute certificates. The Attribute Authority is responsible for this during the entire lifecycle of the attribute certificate, not only during registration.

Attribute Certificate: A data structure that contains a collection of attributes plus additional information for an end user, signed with the private key from the AA that issued the certificate.

Attribute: Information belonging to an object (person or entity) that specifies a characteristic of that entity, such as group membership, a role or other authorization information connected with the holder of an attribute certificate issued for this.

Audit Report: A report from a Qualified Auditor stating the Qualified Auditor’s opinion on whether an entity’s processes and controls comply with the mandatory provisions of requirements.

Auditor: Person who assesses conformity to requirements as specified in given requirements documents.

Authentication Certificate: A certificate which can be used to authenticate a person or a system to a system (G4 certificates only)

Authentication:

1. Verifying someone’s identity before information transfer takes place.
2. Verifying the correctness of the sender’s message.

Authenticity Certificate: A certificate which can be used to authenticate a person or a system to a system (G3 and G1 private certificates only) and/or sign documents to guarantee they are unmodified in any way

Authority for Digital Infrastructure (RDI, Dutch: Rijksinspectie Digitale Infrastructuur): The designated Supervisory Body (SB) as described in Article 17 of regulation 910/2014 (eIDAS). RDI is responsible for admittance (to the national trusted list) and supervision of Trust Service Providers within the Netherlands.

Authorization: The function of specifying access rights/privileges to resources, which is related to general information security and computer security, and to access control in particular.

Authorized representative: A natural person that is authorized to represent an organization. Authority for representation can flow from the act or from general power of attorney. There can also be more than one natural person, for example, a board of an association, authorized to represent an organization.

The table below describes who is normally authorized to represent a certain organization;

Automatic Certificate Management Environment (ACME): A communications protocol for automating interactions between certificate authorities and their users’ servers, enabling automated deployment of PKI. The protocol has been published as an Internet Standard in RFC 8555 by its own chartered IETF working group.

Autonomous Devices Certificate: The certificate holder is a device, the operation and production method of which demonstrably conform to the framework of standards of a specific type of autonomous devices and, in this capacity, is authorized by the party responsible for establishing the framework to use an Autonomous Devices Certificate linked to this device.

Availability: The availability and accessibility of the relevant data. Concerning the infrastructure: the extent to which a system is usable at the moment that it is needed.

Base Domain Name: The portion of an applied-for FQDN that is the first Domain Name node left of a registry-controlled or public suffix plus the registry‐controlled or public suffix (e.g. “example.co.uk” or “example.com”). For FQDNs where the right-most Domain Name node is a gTLD having ICANN Specification 13 in its registry agreement, the gTLD itself may be used as the Base Domain Name.

Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (BR): Stricter and uniform standards for the management of CAs and issuance of TLS Certificates developed by the CA/Browser Forum. They include requirements on identity vetting, certificate content and profiles, CA security, certificate revocation mechanisms, use of algorithms and key sizes, audit requirements, liability, privacy and confidentiality, and delegation of authority.

Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates (SBR): Stricter and uniform standards for the management of CAs and issuance of S/MIME Certificates developed by the CA/Browser Forum. They include requirements on identity vetting, certificate content and profiles, CA security, certificate revocation mechanisms, use of algorithms and key sizes, audit requirements, liability, privacy and confidentiality, and delegation of authority.

Basic Encoding Rules (BER): Specifies in general terms, a partially self-describing and self-delimiting protocol for encoding ASN.1 data structures. Each data element is to be encoded as a type identifier, a length description, the actual data elements, and, where necessary, an end-of-content marker.

Biometrics: A technology for recognising persons or verification on the basis of a unique physical characteristic. For example: iris scan, fingerprint scan, facial recognition.

Blank Cards: Cards (particularly smartcards) that are pre-printed graphically, but not yet provided with key material or personal data.

Bridge Certification Authority – Bridge CA: A Certification Authority serving as pivot in a network of other recognized Certification Authorities that are interoperable. This Certification Authority thus forms a bridge between the various Certification Authorities.

CA Certificate: A certificate from a Certification Authority. A special case of this within the PKI for the government is the CA Certificate from the TSP CA, that is issued by the Policy Authority. This certificate is called the TSP certificate. See also the diagram under “Hierarchical model”.

CA Signing: The signing of a CA certificate. This can be the case when a CA is produced within the hierarchy. This also takes place for cross-certification. In fact this is mutual CA signing. See also the diagram under “Hierarchical model”.

CA/Browser Forum (CABF): A voluntary consortium of certification authorities, vendors of Internet browser and secure email software, operating systems, and other PKI-enabled applications that promulgates industry guidelines governing the issuance and management of X.509 digital certificates that chain to a trust anchor embedded in such applications. Its guidelines cover certificates used for the TLS protocol, S/MIME, and code signing, as well as system and network security of certificate authorities.

CEN Workshop Agreement - CWA: A document from the European Committee for Standardization (CEN) containing advice and proposals for European standardization. Compared to an ETSI standard, the implementation of an CWA is usually faster. However, an ETSI standard is considered as an official starting point.

Canonical Encoding Rules (CER): A restricted variant of BER for producing unequivocal transfer syntax for data structures described by ASN.1. Whereas BER gives choices as to how data values may be encoded, CER (together with DER) selects just one encoding from those allowed by the basic encoding rules, eliminating the rest of the options. CER is useful when the encodings must be preserved; e.g., in security exchanges.

Certificate: An electronic confirmation that connects data for verifying electronic signatures with a certain person and confirms the identity of that person. [Electronic Signatures Act]

Within the scope of the PKI for the government:

The public key of an end user, together with additional information. A certificate is encrypted with the private key of the Certification Authority that issued the public key, which makes the certificate tamper-proof. See also the diagram under “Hierarchical model”.

Certificate & Card Management: The procedures concerning maintenance of the certificates and smartcards.

Certificate Application: The process of applying for a certificate.

Certificate being compromised: Any infringement of confidentiality in the exclusive use of a component by authorized persons.

In the framework of the PKI for the government, the private key is mostly intended with this component. A key is considered invalidated in the event of:

• unauthorized access or intended unauthorized access;
• lost or possibly lost private key or SSCD;
• stolen or possibly stolen private key or SSCD; or
• destroyed private key or SSCD.

A compromise is a reason for placing a certificate on the Certificate Revocation List.

Certificate Generation Service: Creates and signs certificates based on the identity and other attributes verified by the registration service. This can include key generation.

Certificate Holder: An entity identified in a certificate as holder of the private key belonging to the public key that is given in the certificate.

Certificate Identifier - Certificate ID: The unique label of a certificate comprising the name of the Certification Authority and the serial number assigned by the Certification Authority.

Certificate Management Process: Processes, practices, and procedures associated with the use of keys, software, and hardware, by which the CA verifies Certificate Data, issues Certificates, maintains a Repository, and revokes Certificates.

Certificate Policy (CP): named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. See ISO/IEC 9594-8/Recommendation ITU-T X.509.

Certificate Policy - CP: A written specified collection of instructions that indicate the applicability of a certificate for a certain community and/or application class with common security requirements. Using a CP, end users and relying parties can determine how much trust they can place in the connection between the public key and the identity of the holder of the public key.

Certificate Problem Report: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.

Certificate Profile: A set of documents or files that defines requirements for Certificate content and Certificate extensions in accordance with Section 7, e.g. a Section in a CA’s CPS or a certificate template file used by CA software.

Certificate Revocation List (CRL): Signed list indicating a set of certificates that have been revoked by the certificate issuer. Within the scope of the present document the set of certificates is related to end user certificates. See ISO/IEC 9594-8/Recommendation ITU-T X.509.

Certificate of Conduct: An official document issued as a result of a background check by a government agency of a country to enumerate any criminal records the applicant may have. Criminal records may include arrest, conviction, and possibly criminal proceedings.

Certificate validity period (NL: Certificaatgeldigheidsduur): The time period during which the Certification Authority guarantees the usability of the certificate. The Certification Authority retains validity information concerning the status of a certificate for at least 6 months after the end of the term.

Certificate: The public key of a user, together with some other information, rendered un-forgeable by encipherment with the private key of the certification authority which issued it. See ISO/IEC 9594-8/Recommendation ITU-T X.509.

Certification Authority Authorization (CAA): The CAA DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue.

Certification Authority (CA): Authority trusted by one or more users to create and assign certificates. A CA can be:

• a trust service provider that creates and assigns public key certificates; or
• a technical certificate generation service that is used by a certification service provider that creates and assign public key certificates.

See ISO/IEC 9594-8/Recommendation ITU-T X.509.

Certification Practice Statement (CPS): Statement of the practices which a Certification Authority employs in issuing managing, revoking, and renewing or re-keying certificates. See IETF RFC 3647.

Certification Service Provider: See “Trust Service Provider”.

Certification Services: Creation, issuance, revocation, and management of Certificates.

Certification: A broad (both technical and non-technical) evaluation of the security properties of an information system. Certification is implemented as part of a process that measures the extent to which a management system conforms to an agreed collection of requirements. The instruction for certification are recorded in a scheme.

Client Certificate: See “End User Certificate”.

Client: See “End User”.

Common Criteria (CC): A collection of internationally accepted semantic aids and constructions to define a customer’s security requirements and the safety characteristics of systems and products with IT security functions. Common Criteria form an aid when developing and purchasing such products and systems. Such a product or system is called a TOE during the evaluation on the basis of the Common Criteria.

Common Data Security Architecture - CDSA: This architecture provides an open, platform-independent, interoperable and expandable software framework that comprises APIs that are designed to make computer platforms more secure for applications.

Common Name (CN): An attribute which specifies an identification of an object. It is a (possibly ambiguous) name by which the object is commonly known in some limited scope (such as an organization) and conforms to the naming conventions of the country or culture with which it is associated. An attribute value for Common Name is a string chosen by either the person or organization it describes or the organization responsible for the object it describes for devices and application entities.

Compulsory Identification Act (Dutch: Wet op de identificatieplicht): Dutch act stating which proof of identity can be used to determine the identity of persons.

Confidentiality Certificate: A certificate which has been issued to be used for confidentiality services.

Conformity Assessment: Process demonstrating whether specified requirements relating to a product, process, service, system, person or body have been fulfilled.

Control: “Control” (and its correlative meanings, “controlled by” and “under common control with”) means possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors; or (3) vote that portion of voting shares required for “control” under the law of the entity’s Jurisdiction of Incorporation or Registration but in no case less than 10%.

Coordinated Universal Time (UTC): UTC is the primary time standard globally used to regulate clocks and time. It is defined in Recommendation ITU-R TF.460-6 [i.8].

Country: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations.

Critical Security Event: Detection of an event, a set of circumstances, or anomalous activity that could lead to a circumvention of a Zone’s security controls or a compromise of a Certificate System’s integrity, including excessive login attempts, attempts to access prohibited resources, DoS/DDoS attacks, attacker reconnaissance, excessive traffic at unusual hours, signs of unauthorized access, system intrusion, or an actual compromise of component integrity.

Cross-certification: An investigation by one or more Certification Authorities implemented according to each other’s working method and an assessment of the applicable Certificate Policies and Certification Practice Statements.

The goal of this process is to provide certificates from another PKI with a certain trust level within the “own” PKI, so that it is possible to accept each other’s certificates.

Cross-recognition: A situation in which different PKIs recognize each other without signing each other’s keys. A consequence of cross-recognition is that end-users of the PKIs can communicate with each other electronically on the same trust level.

Cryptographic Module: The collection of hardware, software and firmware that implements cryptographic processes, or any combination of these, including cryptographic algorithms, and that is contained within the cryptographic boundaries of the module.

Cryptographic Profile: A collection of cryptographic algorithms and other functions relevant for security, such as hash functions, together with the parameter boundaries that are used to make or verify electronic signatures.

Cryptographically Secure Pseudorandom Number Generator (CSPNG): A pseudorandom number generator (PRNG) with properties that make it suitable for use in cryptography.

Data Encryption Standard (DES): The standard symmetrical cryptographic method from NIST that uses a 560 bit key. The method uses a ‘block cypher’ method that splits the text in blocks of 64 bits and then encrypts these according to blocks. DES is a fast algorithm and is generally used.

Data To Be Signed - DTBS: All electronic data that needs to be signed, including the characteristics of the signatory’s document and the electronic signature.

Decryption: Rendering the encrypted data legible again using a cryptographic key. In the case of symmetrical encryption, the decryption key is the same as the encryption key. In the case of asymmetrical encryption the keys are unequal and the keys are then called public key and private key.

Delegated OCSP Responder: An OCSP Responder with status responses not signed by the CA certificate itself but a dedicated OCSP signing certificate issued by the CA.

Delegated Third Party: natural person or Legal Entity that is not the CA but is authorized by the CA, and whose activities are not within the scope of the appropriate CA audits, to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein.

Denial of Service (DoS) Attack: A cyber-attack in which the perpetrator seeks to make a machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a host connected to a network.

Device Validated: Refers to a Certificate Subject that includes Device attributes. Examples of device attributes are e-mail addresses, domain names, serial numbers, MAC addresses, etc. These attributes may be combined with a subject:organizationName (an associated Legal Entity) attribute.

Digital Signature: Data appended to, or a cryptographic transformation of a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery, e.g. by the recipient. See ISO/IEC 7498-2/Recommendation ITU-T X.800.

Digital identity: See “Electronic Identity”.

Directory service: A TSP service (or one in cooperation with a TSP) that makes the certificates issued by the Certification Authority accessible on line for the benefit of consulting or relying parties.

Disaster (NL:Calamiteit): An unplanned situation in which it is expected that the unavailability of one or more services will exceed the agreed threshold values.

Dissemination Service: Makes certificates available to subjects, and if the subject consents, makes them available to relying parties. This service also makes available the TSP’s terms and conditions, and any published policy and practice information, to subscribers and relying parties.

Distinguished Encoding Rules (DER): A restricted variant of BER for producing unequivocal transfer syntax for data structures described by ASN.1. Like CER, DER encodings are valid BER encodings. DER is the same thing as BER with all but one sender’s options removed.

Distinguished Name (DN): An attribute type for specifying the name of an object.

Domain Certificate Policy – Domain CP: The Certificate Policy relating to a domain certificate.

Domain Certification Authority – Domain CA: The certification authority that produces TSP certificates within a domain. See also the diagram under “Hierarchical model”.

Domain Name System (DNS): A hierarchical and distributed naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names (identification strings) assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols.

Domain Name: The label assigned to a node in the Domain Name System.

Domain certificate: A certificate issued by the Government CA and Domain CA under responsibility of the Policy Authority (PA).

eIDAS Regulation: An EU regulation with the stated purpose of governing electronic identification and trust services for electronic transactions.

Electronic Identification (eID): A digital solution for proof of identity of citizens or organizations. They can be used to view to access benefits or services provided by government authorities, banks or other companies, for mobile payments, etc.

Electronic Signature: A signature that comprises electronic data that are attached to or associated logically with other electronic data and that are used as a means of authentication.

Electronic identity: The data in electronic form that is added to or connected in a logical way with other electronic data and functions as unique characteristic of the identity of the owner. Sometimes the term “Digital Identity” is used.

Electronic-signature product (NL: Product voor elektronische handtekeningen): Software or hardware, or relevant components of this that can be used by trust service providers to provide services in the area of electronic signatures or that can be used for verifying electronic signatures. [European Directive]

Elliptic Curve Algorithm: Also known as Elliptical curve cryptography (ECC). This is a public key encryption technique based on elliptic curve theory that can be used to create faster, smaller and more efficient cryptographic keys compared to classic RSA cryptography.

Elliptic Curve Digital Signature Algorithm (ECDSA): This cryptographic algorithm is used to create digital signatures, which can verify the authenticity and integrity of digital messages or documents. ECDSA relies on the properties of elliptic curve cryptography to provide secure digital signatures

Encryption: The process of converting the original representation of information, known as plaintext, into an alternative form known as ciphertext. This ciphertext is (ideally) unreadable by anyone except the intended recipient

End user (NL: Eindgebruiker): A natural or legal person that has a certificate issued by a TSP, but cannot issue a certificate itself. The term “User” is also sometimes used.

End user certificate (NL:Eindgebruikercertificaat): A certificate issued by a Trust Service Provider to an entity, such as a person, a computer or a piece of information, that cannot issue certificates itself.

Because the end user that receives a certificate from a Trust Service Provider is often referred to as its client, this certificate is also called a client certificate. The term “user certificate” is also sometimes used.

Enhanced Extended Validation Certificates Policy – EVCP+: A Certificate Policy in addition to the NCP+ policy that has to be applied in issuing Extended Validation (EV) SSL certificates on the basis of the EV Guidelines issued by the CAB Forum. This is used in situations in which the use of an SUD is deemed necessary.

eNIK: The planned electronic Dutch Identity Card that is expected to contain the PKloverheid Certificates.

Entry: A separate piece of information that is/becomes included in a register, computer etc.

eSeal: Stands for Electronic Seal. It is an electronic signature that is associated with a legal entity (business or organization) and can be used by more than one person within the legal entity. In the context of this CP an eSeal is a qualified certificate issued by a TSP which is subject to the eIDAS regulation. An eSeal can be  used to automatically sign large volumes of documents (bulk signing),  such as invoices or insurance policies.

eSignature: An electronic Signature (eSignature) is a digital signature over a document or file which is created with the use of a (qualified) PKI-certificate. The goal of this electronic signature is to confirm the identity of the signer in a reliable way (non-repudiation).

European Commission (EC): The European Commission is one of the main institutions of the European Union (EU). It is responsible for proposing legislation, implementing decisions, upholding the EU treaties, and managing the day-to-day business of the EU. The European Commission plays a significant role in the implementation and oversight of the eIDAS (Electronic Identification and Trust Services) Regulation

European Committee for Electrotechnical Standardization (CENELEC, French: Comité Européen de Normalisation Électrotechnique): CENELEC is responsible for European standardization in the area of electrical engineering. Together with ETSI (telecommunications) and CEN (other technical areas), it forms the European system for technical standardization.

European Committee for Standardization (CEN, French: Comité Européen de Normalisation): CEN is a public standards organization whose mission is to foster the economy of the European Single Market and the wider European continent in global trading, the welfare of European citizens and the environment by providing an efficient infrastructure to interested parties for the development, maintenance and distribution of coherent sets of standards and specifications.

European Norm (EN): Technical standards drafted and maintained by CEN (European Committee for Standardization), CENELEC (European Committee for Electrotechnical Standardization) and/or ETSI (European Telecommunications Standards Institute).

European Standards Organization (ESO): An organization responsible for supporting European regulations and legislation through the creation of Harmonised European Standards. CEN, CENELEC and ETSI are the only organizations recognized as ESO.

European Telecommunications Standards Institute (ETSI): European Standards Organization (ESO) which is recognized as a regional standards body dealing with telecommunications, broadcasting and other electronic communications networks and services. It supports European regulations and legislation through the creation of Harmonised European Standards. Only standards developed by the three ESOs (CEN, CENELEC and ETSI) are recognized as European Norms (ENs).

European Union Trust List (EUTL): The Adobe specific name for the List of Trusted lists (LOTL)

Evaluation Assurance Level (EAL): Evaluation Assurance Level (EAL) is a numerical rating assigned to IT products or systems after they undergo security evaluations based on the Common Criteria (CC) framework. Common Criteria is an international standard (ISO/IEC 15408) used for evaluating and certifying the security features and capabilities of information technology products and systems.

Expiry Date: The “Not After” date in a Certificate that defines the end of a Certificate’s validity period.

Extended Normalized Certificate Policy (NCP+): Certificate Policy offering the same quality as that offered by the NCP for use where a secure cryptographic device (signing or decrypting) is considered necessary.

Extended Validation (EV): Validation method proving the legal entity of the owner of a Private Key.

Federal Information Processing Standard (FIPS): A set of standards that describe document processing, encryption algorithms and other information technology standards for use within non-military government agencies and by government contractors and vendors who work with the agencies.

Fully Qualified Domain Name (FQDN): A Domain Name that includes the Domain Labels of all superior nodes in the Internet Domain Name System.

General Data Protection Regulation (GDPR): Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data.

Generation: This Programme of requirements defines several Generations of root certificates. The current 4th generation of Root certificates is designated as G4.

Government Entity: A government‐operated legal entity, agency, department, ministry, branch, or similar element of the government of a country, or political subdivision within such country (such as a state, province, city, county, etc.).

Hardware Security Module (HSM): A physical computing device that safeguards and manages secrets (most importantly digital keys), performs encryption and decryption functions for digital signatures, strong authentication and other cryptographic functions.

Hash function: A function that can be used to map data of arbitrary size to (generally) fixed-size values. It has the property that is practically unfeasible to find two random messages that have the same output (“strong collision-free”) as result. Within PKI cryptographic hash functions are used which have two additional properties: it is practically unfeasible for a given output to find an input that has this (“one-way”) output as a result, and it is practically unfeasible for a given input to find a second input that has this same (“weak collision-free”) output as a result.

High Risk Certificate Request: A certificate request that the TSP flags for additional scrutiny by reference to internal criteria and databases maintained by the TSP, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the TSP identifies using its own risk‐mitigation criteria.

Hypertext Transfer Protocol (HTTP): An application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web.

IP Address: A 32-bit or 128-bit number assigned to a device that uses the Internet Protocol for communication.

Incident: An event that does not form part of the standard working of a service and that has caused or can cause an interruption or a reduction in the quality of the service.

Individual: An individual is that which exists as a distinct entity. Within the context of this CP it means a Natural Person, not being a Legal Person or a machine.

Individual-Validated: Refers to a Certificate Subject that includes only Individual (Natural Person) attributes, rather than attributes only linked to an Organization.

Intermediate certificate: CA signed by the Root CA, or a Subordinate CA, but which itself does not issue end-entity certificates.

Internal Name: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA’s Root Zone Database.

International Alphabet 5 (IA5): A character encoding described in ITU-T Recommendation T.50.

International Electrotechnical Commission (IEC): An international standards organization that prepares and publishes international standards for all electrical, electronic and related technologies.

International Organization for Standardization (ISO): An independent, non-governmental, international standard development organization composed of representatives from the national standards organizations of member countries.

International Telecommunication Union (ITU): A specialized agency of the United Nations responsible for many matters related to information and communication technologies.

International Telecommunication Union Telecommunication Standardization Sector (ITU-T): one of the three Sectors (branches) of the International Telecommunication Union (ITU). It is responsible for coordinating standards for telecommunications and Information Communication Technology, such as X.509 for cybersecurity.

Internationalized Domain Names (IDN): An Internet domain name that contains at least one label displayed in software applications, in whole or in part, in non-Latin script or alphabet or in the Latin alphabet-based characters with diacritics or ligatures.

Internationalized Domain Names in Applications (IDNA): Usage of IDNs in applications.

Internet Assigned Numbers Authority (IANA): Organization responsible for overseeing global IP address allocation, root zone management in the Domain Name System (DNS), autonomous system number allocation, and other Internet Protocol-related symbols and numbers.

Internet Engineering Task Force (IETF): A standards organization for the Internet and is responsible for the technical standards that make up the Internet protocol suite

Issuer Distinguished Name (IDN): Distinguished Name of a certificate’s issuer.

Issuing CA: In relation to a particular Certificate, the CA that issued the Certificate. This could be either a Root CA or a Subordinate CA.

Jurisdiction of Incorporation: The country and (where applicable) the state or province or locality where the organization’s legal existence was established by a filing with (or an act of) an appropriate government agency or entity (e.g., where it was incorporated). In the context of a Government Entity, the country and (where applicable) the state or province where the Entity’s legal existence was created by law.

Key Compromise: A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it.

Key Life-Cycle: A combination of processes, technologies, and policies used to control the life-cycle of keys used in PKIs.

Key Pair: The Private Key and its associated Public Key.

LDH-Label: A label that conforms to the hostname format defined in Request for Comments (RFC) 952, as modified by RFC 1123. LDH labels can consist of ASCII letters, digits, or hyphens. A hyphen must not occupy the first or last position of the label.

Legal Entity: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country’s legal system.

Legal Representative: A natural person who represents a Legal Entity under authority recognized by law.

List of Trusted Lists (LOTL): The European Commission published an aggregated list of national Trusted Lists for consumption by relying parties.

Logius: Digital government service of the Netherlands Ministry of the Interior and Kingdom Relations (BZK). It maintains government-wide ICT solutions and common standards, that simplify the communication between authorities, citizens and businesses, with a view to cohesion of the e-government networks.

Microsoft Active Directory Domain: A logical group of objects that share common administration, security and replication settings, in a Microsoft Active Directory installation.

Microsoft User Principal Name (MSUPN): An Internet-style login name for a user based on the Internet standard RFC 822 used by Microsoft

Mozilla Root Store Policy (MRSP): Official Mozilla policy for CA certificates that are distributed with Mozilla software products.

National Accreditation Body: Sole body in a State that performs accreditation with authority derived from the State. This is equivalent to national accreditation body as specified in point 11 Article 2 of Regulation (EC) No 765/2008.

National Cyber Security Centre (NCSC): A Dutch government computer security organization which is part of the Ministry of Justice and Security whose mission it is to increase the resilience of Dutch society in the digital domain. It focuses on businesses and government departments.

National Institute of Standards and Technology (NIST): An agency of the United States Department of Commerce whose mission is to promote American innovation and industrial competitiveness.

National Scheme: A scheme adopted by a national standardization body.

Natural Person: An Individual; a human being as distinguished from a Legal Entity.

Network and Certificate System Security Requirements (NetSec): Stricter and uniform security standards for networks and information systems used in the management of CAs and the issuance of certificates. It is developed by the CA/Browser Forum and includes requirements on

• General Protections for the Network and Supporting Systems,
• Trusted Roles, Delegated Third Parties, and System Accounts,
• Logging, Monitoring, and Alerting, and
• Vulnerability Detection and Patch Management.

Non-Reserved LDH (NR-LDH) Label: An NR-LDH label is an LDH label whose third and fourth characters are not both -.

Non-repudiation: A service that provides proof of the integrity and origin of data.

Normalized Certificate Policy (NCP): Certificate Policy which meets general recognized best practice for TSPs issuing certificates used in support of any type of transaction.

OCSP Responder: An online server operated under the authority of the CA and connected to its Repository for processing Certificate status requests. See also, Online Certificate Status Protocol.

Object Identifier (OID): A unique alphanumeric or numeric identifier registered under the International Organization for Standardization’s applicable standard for a specific object or object class.

Octet: A unit of digital information in computing that consists of eight bits.

Onion Domain Name: A Fully Qualified Domain Name ending with the RFC 7686 .onion Special-Use Domain Name. For example, 2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion is an Onion Domain Name, whereas torproject.org is not an Onion Domain Name.

Online Certificate Status Protocol (OCSP): An online Certificate-checking protocol that enables relying-party application software to determine the status of an identified Certificate. See also OCSP Responder.

Organization Identification Number (OIN, Dutch: organisatie-identificatienummer): A unique number that Logius can assign to organizations to identify, authenticate and/or authorize themselves in digital messaging within and with the Dutch government. The OIN is for both public and private organizations that exchange messages with the Dutch government.

Organization-Validated: Refers to a Certificate Subject that includes only Organizational (Legal Entity) attributes, rather than attributes linked to an Individual.

Overview of Applicability (OoA): An authority that sets the rules for that part of the hierarchy of a PKI that rests under its authority.

PKI Disclosure Statement: That part of the TSP’s Terms and Conditions which relate to the operation of the PKI.

PKIoverheid: The entire infrastructure that is maintained by the PA PKIoverheid.

Personal Name: Personal Name is a name of an Individual Subject typically presented as subject:givenName and subject:surname.

Policy Authority (PA): An authority that sets the rules for that part of the hierarchy of a PKI that rests under its authority.

Private Key Escrow: A storage method for (a copy of) a private key, in which this is lodged with a trusted third party. If necessary, authorized involved parties can obtain access to the key.

Private Key: The key of a Key Pair that is kept secret by the holder of the Key Pair, and that is used to create Digital Signatures and/or to decrypt electronic records or files that were encrypted with the corresponding Public Key.

Profession-related certificate holder: The certificate holder is a practitioner of a recognized profession and in this capacity is a subscriber and therefore a contracting party.

Program of Requirements (PoR): This document.

Protection Profile (PP): A collection of security requirements, independent of the implementation, for a category of TOEs that needs to satisfy specific customer requirements.

Pseudonym: A fictitious identity that a person assumes for a particular purpose. Unlike an anonymous identity, a pseudonym can be linked to the person’s real identity.

Pseudorandom Number Generator (PRNG): An algorithm for generating a sequence of numbers whose properties approximate the properties of sequences of random numbers. The PRNG-generated sequence is not truly random, because it is completely determined by an initial value, called the PRNG’s seed (which may include truly random values). Although sequences that are closer to truly random can be generated using hardware random number generators, pseudorandom number generators are important in practice for their speed in number generation and their reproducibility.

Public Key Cryptography Standard (PKCS): A standard in the area of public key cryptography, developed by RSA laboratories. In the framework of the PKI for the government particularly PKCS#7 (Cryptographic Message Syntax Standard), PKCS#10 (Certification Request Syntax Specification), PKCS#11 (Cryptographic Token Interface Standard), PKCS#12 (Personal Information Exchange Syntax Standard) and PKCS#15 (Cryptographic Token Information Format Standard) are of importance.

Public Key Cryptography: The system in which a mechanism of public keys and private keys are used. This entails two keys being used. One key is kept secret (the private key) and the other key may be distributed publicly (the public key). Everything that is encrypted with the public key can only be decrypted with the private key and vice versa. It is a form of asymmetric encryption.

Public Key Infrastructure (PKI): A set of hardware, software, people, procedures, rules, policies, and obligations used to facilitate the trustworthy creation, issuance, management, and use of Certificates and keys based on Public Key Cryptography.

Public Key: The key of a Key Pair that may be publicly disclosed by the holder of the corresponding Private Key and that is used by a Relying Party to verify Digital Signatures created with the holder’s corresponding Private Key and/or to encrypt messages so that they can be decrypted only with the holder’s corresponding Private Key.

Publicly-Trusted Certificate: Certificate that is trusted by virtue of the fact that its corresponding Root Certificate is distributed as a trust anchor in widely-available application software.

Punycode: A representation of Unicode with the limited ASCII character subset used for Internet hostnames.

Qualified Auditor: A natural person or Legal Entity that meets the requirements of Section 8.2.

Qualified Certificate: Qualified Certificate as specified in Regulation (EU) No 910/2014.

Qualified Electronic Signature: An electronic signature that is compliant with EU Regulation No 910/2014 (eIDAS Regulation) for electronic transactions within the internal European market. It enables to verify the authorship of a declaration in electronic data exchange over long periods of time. Qualified electronic signatures can be considered as a digital equivalent to handwritten signatures.

Qualified Electronic Signature/Seal Creation Device (QSCD): Device as specified in Regulation (EU) No 910/2014.

Quality Assurance: Systematic process used to determine if a product or service meets quality standards.

Re-Key: The process of creating a new certificate with a new validity period, serial number, and public key while retaining all other Subscriber information in the original certificate.

Registration Authority (RA): Entity that is responsible for identification and authentication of subjects of certificates mainly. See IETF RFC 3647.

Registration Service: Verifies the identity and if applicable, any specific attributes of a subject. The results of this service are passed to the certificate generation service.

Regulated Profession Validated: Refers to a Certificate Subject which combines Individual (Natural Person) attributes in conjunction with a subject:title (an associated Regulated Profession) attribute.

Regulated Profession with Sponsor Validated: Refers to a Certificate Subject which combines Individual (Natural Person) attributes in conjunction with both a subject:title (an associated Regulated Profession) attribute and a subject:organizationName (an associated Legal Entity) attribute.

Regulated Profession: A professional activity or group of professional activities, access to which, the pursuit of which, or one of the modes of pursuit of which, including the use of a professional title, is subject, directly or indirectly, by law or pursuant to law, to the possession of specific professional qualifications, or a profession practiced by members of the associations or organizations listed in Annex I of Directive No. 2005/36/EC of the European Parliament and of the Council of the European Union of 7 September 2005 on the recognition of professional qualifications (OJEU L 255).

Reliable Data Source: An identification document or source of data used to verify Subject Identity Information that is generally recognized among commercial enterprises and governments as reliable, and which was created by a third party for a purpose other than the Applicant obtaining a Certificate.

Reliable Method of Communication: A method of communication, such as a postal/courier delivery address, telephone number, or email address, that was verified using a source other than the Applicant Representative.

Relying Party: Any natural person or Legal Entity that relies on a Valid Certificate. An Application Software Supplier is not considered a Relying Party when software distributed by such Supplier merely displays information relating to a Certificate.

Repository: An online database containing publicly-disclosed PKI governance documents (such as Certificate Policies and Certification Practice Statements) and Certificate status information, either in the form of a CRL or an OCSP response.

Request for Comments (RFC): A Request for Comments (RFC) is a publication in a series from the principal technical development and standards-setting bodies for the Internet, most prominently the Internet Engineering Task Force (IETF).[1][2] An RFC is authored by individuals or groups of engineers and computer scientists in the form of a memorandum describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems. It is submitted either for peer review or to convey new concepts, information, or, occasionally, engineering humor.

Reseller: A Reseller is a person or party who acts as an intermediary between the TSP and the Subscriber. They are not part of the CA/RA systems of a TSP and hence not subject to audit requirements or this CP.

Reserved IP Address: An IPv4 or IPv6 address that is contained in the address block of any entry in either of the following IANA registries:

• https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
• https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

Resource Description Framework (RDF): A World Wide Web Consortium (W3C) standard originally designed as a data model for metadata. It has come to be used as a general method for description and exchange of graph data. RDF provides a variety of syntax notations and data serialization formats.

Revocation Management Service: Processes requests and reports relating to revocation to determine the necessary action to be taken. The results of this service are distributed through the revocation status service.

Revocation Status Service: Provides certificate revocation status information to relying parties.

Revocation: Permanent termination of the certificate’s validity before the expiry date indicated in the certificate.

Risk Assessment: A Risk assessment is a process which determines possible mishaps and incidents plus their likelihood and consequences, and the tolerances for such events. The results of this process may be expressed in a quantitative or qualitative fashion and determine the TSP’s approach to mitigate or accept these (residual) risks.

Rivest-Shamir-Adleman (RSA) Algorithm: RSA a public-key cryptosystem, one of the oldest widely used for secure data transmission. It relies on the principle of public-key cryptography, in which the encryption key is public and distinct from the decryption key, which is kept secret (private). An RSA user creates and publishes a public key based on two large prime numbers, along with an auxiliary value. The prime numbers are kept secret. Messages can be encrypted by anyone, via the public key, but can only be decrypted by someone who knows the private key.

Root CA: The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.

Root Certificate: The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs.

S/MIME Capable Certificate: A Secure/Multipurpose Internet Mail Extensions (S/MIME) PKI certificate is a certificate that is capable of signing and/or encrypting email messages. This is indicated through the use of certain policy OIDs (PKIoverheid or CA/Browser Forum specific) and the inclusion of the Extended Key Usage (EKU) emailProtection in a certificate.

Secure Cryptographic Device (SCD): Device which holds the subject’s private key, protects this key against compromise and performs signing or decryption functions on behalf of the subject.

Secure Hash Algorithm (SHA): Is a family of hash functions mainly designed by the National Institute of Standards and Technology(NIST). A hash function is used to represent a shortened version of the original message that is cryptographically secure. This can be used in PKI to sign data or certificates.

Secure Multi-Purpose Internet Mail Extensions (S/MIME): S/MIME is a standard for public-key encryption and signing of Multipurpose Internet Mail Extensions (MIME), which is an Internet standard that extends the format of email messages to support text in character sets other than ASCII, as well as attachments of audio, video, images, and application programs.

Short-lived Certificate: A Certificate with a Validity Period less than or equal to 7 days (604,800 seconds).

Signature Activation Module (SAM): A software component to authenticate the signer and gain its authorization to activate its signing key for the purpose of signing, ensuring that the signing keys are under the control of the signer.

Single Sign-On (SSO):Aan identification method that enables users to log in to multiple applications and websites with one set of credentials.

Sponsor-validated: Refers to a Certificate Subject which combines Individual (Natural Person) attributes in conjunction with a subject:organizationName (an associated Legal Entity) attribute (in version 4.11 and earlier issued under PoR parts 3a and 3i as “Organization Person”).

Subject Device Provisioning Service: Prepares, and provides or makes available secure cryptographic devices, or other secure devices, to subjects.

Subject Distinguished Name (SDN): Distinguished Name of a certificate’s Subject.

Subject Identity Information: Information that identifies the Certificate Subject. Subject Identity Information does not include a Domain Name listed in the subjectAltName extension or the Subject commonName field.

Subject: The natural person, device, system, unit, or Legal Entity identified in a Certificate as the Subject. The Subject is either the Subscriber or a device under the control and operation of the Subscriber.

Subordinate CA (Sub-CA): Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA.

Subscriber Agreement: An agreement between the CA and the Applicant/Subscriber that specifies the rights and responsibilities of the parties.

Subscriber: A natural person or Legal Entity to whom a Certificate is issued and who is legally bound by a Subscriber Agreement or Terms of Use.

Supervisory Authority (SA): An independent public authority responsible for monitoring the application of the GDPR, in order to protect the fundamental rights and freedoms of natural persons in relation to processing and to facilitate the free flow of personal data within the EU.

TSP certificate: CA certificate of a TSP.

TSP signing: The signing of a TSP certificate. Within the PKI for the government this occurs by using the domain CA’s private key under responsibility of the PA (Policy Authority). See also the diagram under “Hierarchical model”.

Target of Evaluation (TOE): A product or system including the corresponding documentation that is subjected to an evaluation.

Technical Standard (TS): A document that provides requirements, specifications, guidelines or characteristics that can be used consistently to ensure that materials, products, processes and services are fit for their purpose.

Technically Constrained Subordinate CA Certificate: A Subordinate CA certificate which uses a combination of Extended Key Usage and/or Name Constraint extensions, as defined within the relevant Certificate Profiles, to limit the scope within which the Subordinate CA Certificate may issue Subscriber or additional Subordinate CA Certificates.

Terms and Conditions: A document with terms and conditions relating a TSP’s certificate products, which includes at a minimum the following elements:

1. the indication of what constitutes certificate acceptance;
2. the period of time for which records are retained;
3. the Terms of Use for Subscribers and where applicable the Subjects;
4. the User Notice for Relying Parties;
5. the ways in which a specific policy adds to or further constrains the requirements of the CP.

Terms of Use: Obligations and expectations on the safekeeping and acceptable use of issued certificates. The Terms of Use is also part of the Terms and Conditions document.

Top Level Domain (TLD): In the DNS hierarchy, a top-level domain (TLD) represents the first stop after the root zone. In simpler terms, a TLD is everything that follows the final dot of a domain name. For example, in the domain name ‘google.com’, ‘.com’ is the TLD.

Trade Register Number (HRN, Dutch: Handelsregisternummer): A unique number issued by the Dutch Trade Register when a company is incorporated in the Netherlands.

Transport Layer Security (TLS): A widely adopted security protocol designed to facilitate privacy and data security for communications over the Internet. A primary use case of TLS is encrypting the communication between web applications and servers, such as web browsers loading a website.

Trust Service: Electronic service for:

• creation, verification, and validation of digital signatures and related certificates;
• creation, verification, and validation of time-stamps and related certificates;
• registered delivery and related certificates;
• creation, verification and validation of certificates for website authentication; or
• preservation of digital signatures or certificates related to those services.

Trust Service Component: One part of the overall service of a TSP.

Trust Service Provider (TSP): Entity which provides one or more trust services.

Trust Service Provider-Certificate Policy – TSP CP: A Certificate Policy concerning the certificate from the TSP.

Trust Services Decree: Decree of 22 February 2017, laying down requirements for the provision of trust services, repealing the Electronic Signatures Decree and amending a number of other decrees.

Trusted List: A public national list of Trust Service Providers (TSPs) that are specifically accredited to deliver the highest levels of compliance with the EU eIDAS electronic signature regulation. In the Netherlands this is managed by the RDI

Trustworthy System: Computer hardware, software, and procedures that are: reasonably secure from intrusion and misuse; provide a reasonable level of availability, reliability, and correct operation; are reasonably suited to performing their intended functions; and enforce the applicable security policy.

U-Label: The Unicode representation of an internationalized domain name.

Unicode Transformation Format - 8-bit (UTF-8): A variable-length character encoding standard used for electronic communication.

Unicode: A text encoding standard maintained by the Unicode Consortium designed to support the use of text written in all of the world’s major writing systems.

Uniform Resource Identifier (URI): A unique sequence of characters that identifies an abstract or physical resource, such as resources on a webpage, mail address, phone number, books, real-world objects such as people and places, concepts. URIs are used to identify anything described using the Resource Description Framework (RDF).

Uniform Resource Locator (URL): A reference to a resource that specifies its location on a computer network and a mechanism for retrieving it. A URL is a specific type of Uniform Resource Identifier (URI).

User Notice: Notice provided for Relying Parties concerning acceptable use of the certificate. The User Notice is also part of the Terms and Conditions document.

Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280.

Validity Period: The period of time from notBefore through notAfter, inclusive.

Verklaring omtrent het gedrag (VOG): A VOG is a Dutch certificate which shows that someone’s past does not constitute an obstacle to fulfilling a specific task or function in society. When assessing a VOG application, Justis looks at whether the subject has any criminal offenses on its record that pose a risk to the position or purpose for which the subject is applying for in the VOG application.

Verklaring van geen bezwaar (VGB): A VGB is a Dutch statement issued after a security screening by or on behalf of the Minister of the Interior to a person who qualifies for a position involving confidentiality. A security investigation is more thorough than an investigation for a VOG.

Wildcard Domain Name: A string starting with *. (U+002A ASTERISK, U+002E FULL STOP) immediately followed by a Fully-Qualified Domain Name.

World Wide Web Consortium (W3C): The main international standards organization for the World Wide Web.

1.6.3 Acronyms

The acronyms in the table below apply within the PKIoverheid Programme of Requirements. The meanings of most acronyms are explained in Section 1.6.1 “Definitions”.

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1 Repositories

No stipulation.

2.2 Publication of certification information

The TSP Certificate Practice Statement (CPS) SHALL

• fully comply with the layout as stipulated in RFC 3647 and SHALL include all sections and subsections mentioned therein;
• always include the text “No stipulation” in sections for which the TSP has no further requirements or other text;
• be available English, the version of which SHALL be leading in case of interpretation disputes when versions are also made available in other languages;
• be reviewed and renewed yearly, which SHALL be demonstrated by incrementing the CPS’s version number and adding a date to the CPS’s change log (even if no actual changes have been made);
• contain a list of all Issuing Certificates which are in scope of the CPS, including their SHA256 fingerprints;
• contain a list of all certificate policy Object Identifiers (OIDs) of all certificate types described in the CPS;
• contain the validation method(s) used for each and every subject attribute in a certificate, with the additional stipulation that
  • IP address and/or FQDN validation SHALL reference EITHER the section(s) in the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates describing the validation method being used, OR the provided OID(s) of a custom validation method approved by the PA PKIoverheid meant for a specific use case, and
  • E-mail address validation SHALL reference EITHER the section(s) in the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates describing the validation method being used, OR the provided OID(s) of a custom validation method approved by the PA PKIoverheid meant for a specific use case.

Comment

Although a TSP may not have to comply with the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates and/or the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates for any or all of its certificates, certain sections will still be normative within PKIoverheid when explicitly mentioned in this PoR. For certificates which do have to comply with any of these baselines, (parts of) this requirement may be redundant.

2.3 Time or frequency of publication

No stipulation.

2.4 Access controls on repositories

No stipulation.

3. IDENTIFICATION AND AUTHENTICATION

3.1 Naming

3.1.1 Types of names

The types of names which may be used in a certificate SHALL be limited by the restrictions described in Section 7 of this document.

3.1.2 Need for names to be meaningful

No stipulation.

3.1.3 Anonymity or pseudonymity of subscribers

Pseudonyms SHALL NOT be used in certificates.

Comment

eIDAS regulation Article 5 states “the use of pseudonyms in electronic transactions shall not be prohibited” which means certificates containing pseudonyms may not be prohibited in electronic transactions in scope of eIDAS. This however does not mean all certificates used in those transactions should allow pseudonyms. Usage of pseudonyms are not in scope of the use cases currently envisioned for PKIoverheid. Therefore, the PA PKIoverheid does not allow for pseudonyms in PKIoverheid certificates.

3.1.4 Rules for interpreting various name forms

No stipulation.

3.1.5 Uniqueness of names

No stipulation.

3.1.6 Recognition, authentication, and role of trademarks

No stipulation.

3.2 Initial identity validation

3.2.1 Method to prove possession of private key

No stipulation.

3.2.2 Authentication of organization identity

3.2.2.1 Reuse of identify information

Previously verified organization identity information MAY be re-used provided that the TSP obtained the data or completed the validation itself no more than 825 days prior to issuing the Certificate.

Comment 1

In the Netherlands the Trade Registry of the Chamber of Commerce is regarded as the standard reliable data source for verifying Legal Entities. For governmental organizations without an entry in this register, the Staatsalmanak is regarded as the standard reliable data source.

Comment 2

This topic is covered in ETSI 319 411-1 and 411-2, Section 6.2.2.

3.2.2.2 DBA/Tradename

No stipulation.

3.2.2.3 Verification of Country

No stipulation.

3.2.2.4 Validation of Domain Authorization or Control

If one or more FQDNs are included in a certificate request, the TSP SHALL verify each one using a verification process meeting the requirements in Section 3.2.2.4 of the CA/Browser Forum’s “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates”, and that is described in the TSP’s Certification Practice Statement. The same SHALL apply for any included IP addresses, but for which the verification methods can be found in Section 3.2.2.5. However, wildcard and onion domains SHALL NOT be allowed.

These verifications SHALL NOT be outsourced by the TSP and SHALL remain valid for only a single certificate issuance.

Comment

Although a TSP may not have to comply with the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates and/or the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates for any or all of its certificates, certain sections will still be normative within PKIoverheid when explicitly mentioned in this PoR. For certificates which do have to comply with any of these baselines, (parts of) this requirement may be redundant.

3.2.2.5 Authentication for an IP Address

No stipulation.

3.2.2.6 Wildcard Domain Validation

No stipulation.

3.2.2.7 Data Source Accuracy

No stipulation.

3.2.2.8 CAA Records

No stipulation.

3.2.3 Authentication of individual identity

Previously verified individual identity information MAY be re-used provided that the TSP obtained the data or completed the validation itself no more than 825 days prior to issuing the Certificate.

Comment

This topic is covered in ETSI 319 411-1 and 411-2, Section 6.2.2.

3.2.4 Non-verified subscriber information

No stipulation.

3.2.5 Validation of authority

3.2.5.1 Legal representation

When the Applicant is a Legal Entity, the TSP SHALL verify the Legal Representative of the Applicant against a Reliable Data Source.

Previously verified legal representation MAY be re-used provided that the TSP obtained the data no more than 825 days prior to issuing the Certificate.

Comment

In the Netherlands the Trade Registry of the Chamber of Commerce is regarded as the standard reliable data source for verifying Legal Representatives. For governmental organizations without an entry in this register, the Staatsalmanak is regarded as the standard reliable data source.

3.2.5.2 Delegated representation

When the Applicant is a Legal Entity, the TSP SHALL verify the chain of authorization from the Applicant’s Legal Representative to the Applicant Representative, including any and all intermediate representatives, using trustworthy communication and offering non-repudiation with an appropriate level of reliability.

Previously verified delegated representation MAY be re-used provided that the TSP obtained the data or completed the validation itself no more than 825 days prior to issuing the Certificate.

Comment

A PDF or E-mail in which a Legal Representative authorizes an Applicant Representative, and which is signed with a Qualified signature, definitely counts as “trustworthy communication and offering non-repudiation with an appropriate level of reliability”. Whether an authorization in a letter with a hand-written signature by the Legal Representative (including a copy of its passport) is good enough, is debatable. This depends on current industry best practices and the view of auditors on this subject. What an appropriate level of reliability is, depends on both internal and external factors, and will always change over time.

3.2.5.3 Regulated professions

Regulated Profession Certificates SHALL be issued only to Subjects which

• have a profession which either
  • is included in the EU Regulated Professions Database (Directive 2005/36/EC), or
  • is included in this limitative list:
    • Notaris (Civil Law Notary);
    • Toegevoegd Notaris (Added Notary);
    • Gerechtsdeurwaarder (Court Bailiff);
    • Those who have been entered into a register as meant in article 3 of the Professions in the individual healthcare Act (Wet op de beroepen in de individuele gezondheidszorg (Wet BIG));
    • Those who practice a profession of which the education is mandated through article 34, section 1 and article 36a of the Professions in the individual healthcare Act (Wet op de beroepen in de individuele gezondheidszorg (Wet BIG));
    • Waarnemend gerechtsdeuraarder (Acting Court Bailiff);
    • Toegevoegd gerechtsdeurwaarder (Additional Court Bailiff);
    • Kandidaat gerechtsdeurwaarder (Junior Court Bailiff);
    • Zeevarende (Seafarer);
    • (Hoofd)bewaarder ((Head) Registrar);
    • Gemandateerd bewaarder Mandated Registrar;
    • Technisch Medewerker schepen (Ships Technician);
    • Inspecteur Scheepsregistraties (Ship Registration Inspector);
    • Belastingdeurwaarder (Government-appointed Tax Bailiff);
    • Rijksdeurwaarder (Government Bailiff);
    • Gemeentelijk Belastingdeurwaarder (Municipal Tax Bailiff), and
• have been validated to be allowed to practice said profession through
  • a trustworthy document (e.g. licence card, certificate, diploma), or
  • against a register of a relevant regulatory body.

Comment

The EU Regulated Professions Database can be found at https://ec.europa.eu/growth/tools-databases/regprof/index.cfm?action=regprofs.

The limitative list in this requirement will be adopted in a future iteration of the EU Regulated Professions Database. After this adoption the list will be removed from this requirement.

3.2.5.4 High-risk certificate request

When the TSP is exposed to potential High Risk Certificate Requests, it SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for these requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified.

3.2.6 Criteria for interoperation

No stipulation.

3.3 Identification and authentication for re-key requests

3.3.1 Identification and authentication for routine re-key

The requirements stipulated for initial identity and authentication validation SHALL also apply for identification and authentication in routine re-key requests.

Comment 1

This means both legal representatives and the chain of authorization from the Legal Representative to the Applicant Representative also have to be verified within the 825-day time frame.

Comment 2

TSPs are encouraged to offer modern re-key technology like Automatic Certificate Management Environment (ACME) when this is useful for their subscribers.

Comment 3

This topic is covered in ETSI 319 411-1 and 411-2, Section 6.2.3.

3.3.2 Identification and authentication for re-key after revocation

The requirements stipulated for initial identity validation SHALL also apply for re-key requests after revocation, except when the reason for revocation involves the subject’s identity information. In that case, all previously validated subject information needs to be re-validated.

3.4 Identification and authentication for revocation request

No stipulation.

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1 Certificate Application

4.1.1 Who can submit a certificate application

No stipulation.

4.1.2 Enrollment process and responsibilities

No stipulation.

Comment

When the name of a Legal Entity changes but not the actual underlying registration number (e.g. HRN), there is no need for re-approval of the Subscriber Agreement. Of course, certificates in these cases do have to be revoked because the subject:organizationName is no longer correct.

4.2 Certificate application processing

4.2.1 Performing identification and authentication functions

No stipulation.

4.2.2 Approval or rejection of certificate applications

No stipulation.

4.2.3 Time to process certificate applications

No stipulation.

4.3 Certificate issuance

4.3.1 CA actions during certificate issuance

No stipulation.

4.3.2 Notification to subscriber by the CA of issuance of Certificate

No stipulation.

4.4 Certificate acceptance

4.4.1 Conduct constituting certificate acceptance

No stipulation.

4.4.2 Publication of the certificate by the CA

No stipulation.

4.4.3 Notification of certificate issuance by the CA to other Entities

No stipulation.

4.5 Key pair and certificate usage

4.5.1 Subscriber private key and certificate usage

No stipulation.

4.5.2 Relying party public key and certificate usage

The Terms of Use SHALL mention the following expectations for safe and acceptable certificate usage:

• the Subscriber is responsible for prompt replacement of its certificate(s) in the event of an approaching expiry of validity, and for emergency replacement in the event of a private key compromise and/or other types of emergencies relating to the certificate or the higher level certificates,
• the Subscriber is expected to take adequate measures in order to safeguard the continuity of the use of certificates, and
• the Subscriber is expected to take into account security best practices in the usage of certificates.

Comment 1

A TSP may refer to the IT Security Guidelines for Transport Layer Security (TLS) document by the Dutch National Cyber Security Centre (NCSC) for secure usage of web server certificates. Check the NCSC website for the latest version of this document.

Comment 2

Subscriber obligations which should be part of the Terms of Use are described in ETSI EN 319 411-1 clauses OVR-6.3.5-01 and OVR-6.3.5-02.

4.6 Certificate renewal

4.6.1 Circumstance for certificate renewal

No stipulation.

4.6.2 Who may request renewal

No stipulation.

4.6.3 Processing certificate renewal requests

No stipulation.

4.6.4 Notification of new certificate issuance to subscriber

No stipulation.

4.6.5 Conduct constituting acceptance of a renewal certificate

No stipulation.

4.6.6 Publication of the renewal certificate by the CA

No stipulation.

4.6.7 Notification of certificate issuance by the CA to other entities

No stipulation.

4.7 Certificate re-key

4.7.1 Circumstance for certificate re-key

No stipulation.

4.7.2 Who may request certification of a new public key

No stipulation.

4.7.3 Processing certificate re-keying requests

No stipulation.

4.7.4 Notification of new certificate issuance to subscriber

No stipulation.

4.7.5 Conduct constituting acceptance of a re-keyed certificate

No stipulation.

4.7.6 Publication of the re-keyed certificate by the CA

No stipulation.

4.7.7 Notification of certificate issuance by the CA to other entities

No stipulation.

4.8 Certificate modification

4.8.1 Circumstance for certificate modification

No stipulation.

4.8.2 Who may request certificate modification

No stipulation.

4.8.3 Processing certificate modification requests

No stipulation.

4.8.4 Notification of new certificate issuance to subscriber

No stipulation.

4.8.5 Conduct constituting acceptance of modified certificate

No stipulation.

4.8.6 Publication of the modified certificate by the CA

No stipulation.

4.8.7 Notification of certificate issuance by the CA to other entities

No stipulation.

4.9 Certificate revocation and suspension

4.9.1 Circumstances for revocation

Certificates SHALL be revoked when

• the TSP has sufficient evidence that the private key associated with a certificate has been compromised or is suspected to be compromised,
• the Subscriber does not meet its obligations set out in the approved Subscriber Agreement,
• the TSP determines that information in the certificate is incorrect or misleading, or
• the PA PKIoverheid determines that the technical content of the certificate entails an irresponsible risk for Subscribers, Relying Parties and/or third parties (e.g. browser parties).

If a certificate contains the keyPurposeId value emailProtection (OID: 1.3.6.1.5.5.7.3.4) in their profile’s extendedKeyUsage extension field, occurrence of the events stipulated in Section 6.2 of the Mozilla Root Store Policy (MRSP) SHALL also result in revocation.

Comment 1

Compromise of a Private Key can be unauthorized access to the key, or loss or destruction of a Private Key medium. A Private Key medium can be a QSCD, SSCD, SUD, or a conventional storage medium.

Comment 2

Although a TSP may not have to comply with the Mozilla Root Store Policy (MRSP) for any of its certificate products, certain sections will still be normative within PKIoverheid when explicitly mentioned in this PoR, including within private hierarchies.

Comment 3

The requirement references Section 6.1 of the Mozilla Root Store Policy (MRSP) as a source of revocation events. These events are described in Section 6.1 only, and not in its sub-sections.

Comment 4

The requirement references Section 6.2 of the Mozilla Root Store Policy (MRSP) as a source of revocation events. Currently this Section only refers to the S/MIME Baseline Requirements of the CA/Browser Forum, making this reference redundant for the certificate types in scope. However, Section 6.2 could be expanded in the future, making this inclusion a sensible catch-all.

4.9.2 Who can request revocation

Authorized sources for certificate revocation requests SHALL include:

• Subject when both the Subject and Subscriber are a natural person,
• Subject when the Subject is a natural person but the Subscriber a Legal Entity,
• Legal Representative when the Subscriber is a Legal Entity,
• any Delegated Legal Representative when the Subscriber is a Legal Entity,
• the TSP itself,
• any other stakeholder described in the TSP CPS for this purpose.

Certificate problem reports originating from ANY source SHALL also result in a certificate revocation request by the TSP if it determines the report supports sufficient evidence to do so.

Comment

Following incident response procedures, a certificate problem report from an unauthorized source may result in a revocation request from an authorized source.

4.9.3 Procedure for revocation request

No stipulation.

4.9.4 Revocation request grace period

No stipulation.

4.9.5 Time within which CA must process the revocation request

No stipulation.

4.9.6 Revocation checking requirement for relying parties

No stipulation.

4.9.7 CRL issuance frequency (if applicable)

No stipulation.

4.9.8 Maximum latency for CRLs (if applicable)

No stipulation.

4.9.9 On-line revocation/status checking availability

If the TSP supports the Online Certificate Status Protocol (OCSP), it SHALL

• sign its responses using a certificate of which the TSP is the subscriber and which is issued within the same root hierarchy as the Certificates whose revocation status is being checked, and
• when offering cached OCSP responses, address the risk of outdated responses and forged responses in an adequate manner based on a risk assessment.

Comment

Caching OCSP responses can introduce the security risks of outdated and/or forged responses. Outdated responses can lead to client software accepting an invalid certificate and exposing itself to a Man-in-the-Middle (MitM) attack or a data breach. Forged responses can trick the client into accepting a revoked or fake certificate, which can also cause a MitM attack or a data breach.

4.9.10 On-line revocation checking requirements

CRL services for on-line Certificate revocation checking SHALL be available.

If OCSP services for on-line revocation checking are available, Section 4.9.10 from the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates SHALL apply.

Comment 1

Although a TSP may not have to comply with the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates and/or the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates, certain sections will still by normative within PKIoverheid when explicitly mentioned in this PoR.

Comment 2

Since OCSP servers can collect IP addresses of persons issuing OCSP requests, this service introduces a privacy risk. Therefore TSPs running an OCSP service need to make sure this service is part of their General Data Protection Regulation (GDPR) processing activities register, and if appropriate, take adequate measures based on the outcome of a Data Protection Impact Assessment (DPIA).

4.9.11 Other forms of revocation advertisements available

No stipulation.

4.9.12 Special requirements related to key compromise

No stipulation.

4.9.13 Circumstances for suspension

Suspension of a certificate SHALL NOT be supported.

4.9.14 Who can request suspension

No stipulation.

4.9.15 Procedure for suspension request

No stipulation.

4.9.16 Limits on suspension period

No stipulation.

4.10 Certificate status services

4.10.1 Operational characteristics

No stipulation.

4.10.2 Service availability

Section 4.10.2 from the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates SHALL apply.

Comment

Although a TSP may not have to comply with the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates and/or the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates, certain sections will still by normative within PKIoverheid when explicitly mentioned in this PoR.

4.10.3 Optional features

No stipulation.

4.11 End of subscription

No stipulation.

4.12 Key escrow and recovery

4.12.1 Key escrow and recovery policy and practices

No stipulation.

4.12.2 Session key encapsulation and recovery policy and practices

No stipulation.

5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

A Risk Assessment as described in Section 5 of ETSI EN 319 401 SHALL be performed by the TSP at least once a year.

Furthermore, the TSP SHALL perform an intermediate Risk Assessments when

• the TSP expands its PKIoverheid product portfolio,
• the PA PKIoverheid decides this is necessary, or
• the NCSC decides this is necessary.

Comment

Section 5 of ETSI EN 319 401 is referenced in Section 6.4.1 of ETSI EN 319 411-1.

5.1 Physical controls

5.1.1 Site location and construction

No stipulation.

5.1.2 Physical access

No stipulation.

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

No stipulation.

5.1.7 Waste disposal

No stipulation.

5.1.8 Off-site backup

No stipulation.

5.2 Procedural controls

Comment

Many CA/B Forum requirements on procedural controls can be found in Section 2 of the Network and Certificate System Security Requirements. ETSI describes its requirements in Section 7.4 of ETSI EN 319 401, which is referenced in both OVR-6.4.3-01 and OVR-6.5.5-01 in ETSI EN 319 411-1.

5.2.1 Trusted roles

No stipulation.

5.2.2 Number of persons required per task

No stipulation.

5.2.3 Identification and authentication for each role

No stipulation.

5.2.4 Roles requiring separation of duties

No stipulation.

5.3 Personnel controls

On appointment to a trusted role, the TSP’s personnel SHALL have an applicable and valid certificate of conduct.

The validity of the certificate of conduct SHALL at a minimum be based on industry best practices in comparable trusted roles.

The TSP SHALL have risk-based processes in place for validating continued reliability of personnel during employment in a trusted role.

Comment 1

Examples of trusted roles include system administrators, security officers, and system auditors.

Comment 2

In the Netherlands a Verklaring Omtrent Gedrag (VOG) is the most common Certificate of Conduct and can be regarded as a baseline. For higher trust levels a Verklaring Geen Bezwaar (VGB) is common.

Comment 3

In most common Dutch security policies (e.g. Dutch health care) it is a best practice to not have a VOG older than three years. For a VGB the maximum life span depends on the screening level, but usually varies between 5 and 10 years (Dutch Department of Defence). However, sometimes collective employment agreements prohibit VOG renewals during employment in certain sectors. In that case the residual risk will have to be part of the risk assessment process stipulated in ETSI EN 319 401 Section 5.

Comment 4

Two examples of risk-based processes for validating continued reliability are requesting a renewed Certificate of Conduct and periodically inspecting the execution of trust processes by Quality Assurance personnel or internal auditors.

Comment 5

This requirement can be regarded as an expansion of ETSI EN 319 401 REQ-7.1-02.

5.3.1 Qualifications, experience, and clearance requirements

No stipulation.

5.3.2 Background check procedures

No stipulation.

5.3.3 Training requirements

No stipulation.

5.3.4 Retraining frequency and requirements

No stipulation.

5.3.5 Job rotation frequency and sequence

No stipulation.

5.3.6 Sanctions for unauthorized actions

No stipulation.

5.3.7 Independent contractor requirements

No stipulation.

5.3.8 Documentation supplied to personnel

No stipulation.

5.4 Audit logging procedures

5.4.1 Types of events recorded

Types of events recorded SHALL comply with requirements stipulated in Section 5.4.1 of the latest version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates by the CA/Browser Forum. The audit log event type definitions described in that Section also apply to this Programme of Requirements, with the following expansions:

1. CA certificate and key life-cycle events also includes
   1. the Terms and Conditions accepted by the subscriber, and if it is a separate person, the subject as well, and
   2. all events related to any subject device provisioning.

Comment

Although not mandatory for most remaining TSP Issuing Certificates, some parts of the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates do have merit for the whole PKIoverheid ecosystem. Therefore, certain sections are adopted in full as general PoR requirements.

5.4.2 Frequency of processing log

No stipulation.

5.4.3 Retention period for audit log

The following audit log event types mentioned in Section 5.4.1 SHALL be retained a minimum of 7 years after any certificate based on these records expires:

• CA certificate and key lifecycle events, and
• Subscriber Certificate lifecycle management events.

The following audit log event types mentioned in Section 5.4.1 SHALL be retained a minimum of 18 months but SHOULD be retained for a minimum of 24 months:

• Security events.

Unless prohibited by law or internal security policies, audit logs SHALL be deleted within 1 year after the minimum retention time, including any back-up copies.

Comment

• Expiry of certificates mentioned above is solely based on the date in its notAfter field, thus excluding any form of revocation.
• The CA/Browser Forum states a minimum retention time of 2 years for all types of audit logs in Section 5.4.3 of both its Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates and its Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates. However, ETSI EN 319 411-2 states a minimum of 7 years retention time specifically for certificate life-cycle events. This means a split had to be made between the different audit log event types.
• Previous versions of this Programme of Requirements had just a minimum retention time of 18 months for security events. In future versions PKIoverheid intends to follow industry best practices and move to a minimum of 24 months retention time. The “SHOULD” language should be read as an encouragement to already take into account this future change.
• The choice of deletion within a year after the minimum audit log retention time is based on balancing GDPR considerations and practicality in log management.

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

No stipulation.

5.5 Records archival

5.5.1 Types of records archived

No stipulation.

5.5.2 Retention period for archive

No stipulation.

5.5.3 Protection of archive

No stipulation.

5.5.4 Archive backup procedures

No stipulation.

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

No stipulation.

5.7 Compromise and disaster recovery

5.7.1 Incident and compromise handling procedures

5.7.1.1 Incident Response and Disaster Recovery Plan

The TSP SHALL comply with Section 5.7.1 of the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates.

Comment 1

The Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates is referenced because Business Continuity requirements were deemed too limited in the ETSI requirements (OVR-6.4.8-05, OVR-6.4.8-08, and OVR-6.4.8-09 in ETSI EN 319 411-1, and REQ-7.11-01 and REQ-7.11-02 in ETSI EN 319 401).

Comment 2

Although a TSP may not have to comply with the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates and/or the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates, certain sections will still by normative within PKIoverheid when explicitly mentioned in this PoR.

5.7.1.2 Communication

When a relevant security or compliance incident occurs the TSP SHALL notify all the appropriate parties mentioned below as quickly as possible but always within 24 hours of discovery, including timely updates of its progress.

The appropriate parties per incident type SHALL at least consist of:

• Critical Security Event: PA PKIoverheid, NCSC, and the Dutch Authority for Digital Infrastructure (RDI);
• Violations of ETSI requirements, including certificate mis-issuance: PA PKIoverheid and the Dutch Authority for Digital Infrastructure (RDI);
• Violations of CA/B Forum and/or PoR requirements, including certificate mis-issuance: PA PKIoverheid.

By default the TSP SHALL use the standard RDI eIDAS Incident Report Form to communicate incident information with the parties mentioned above.

Comment 1

This requirement expands on REQ-7.9-07 in ETSI EN 319 401.

Comment 2

The latest version of the RDI eIDAS Incident Report Form can be requested through the RDI website. Version 2.0 of this document was published on 2023-02-20.

Comment 3

When security events involve personal data, the GDPR imposes additional requirements. This can include notifying the GDPR Supervisory Authority (SA).

5.7.1.3 Vulnerability Management

The TSP SHALL subscribe to the NCSC Advisories and SHALL incorporate reviewing these advisories at least on a weekly basis as part of its Vulnerability Management Proces underlying requirements REQ-7.9-10 and REQ-7.9-11 in ETSI EN 319 401. Additionally, the TSP SHALL have a real-time notification process for advisories needing immediate review.

Comment 1

Information on NCSC Advisories can be found on the NCSC website.

Comment 2

Requirements REQ-7.9-10 and REQ-7.9-11 in ETSI EN 319 401 are referenced in requirement OVR-6.4.8-01 in ETSI EN 319 411-1.

Comment 3

The risk and impact identifiers in the header of an NCSC Advisory can be used to automatically forward the advisory to the appropriate channel(s).

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

No stipulation.

5.7.3 Entity private key compromise procedures

No stipulation.

5.7.4 Business continuity capabilities after a disaster

No stipulation.

5.8 CA or RA termination

No stipulation.

6. TECHNICAL SECURITY CONTROLS

6.1 Key pair generation and installation

6.1.1 Key pair generation

6.1.1.1 CA key pair generation

No stipulation.

6.1.1.2 RA key pair generation

No stipulation.

6.1.1.3 Subscriber key pair generation

If the TSP generates the private key for the Subject, the following SHALL apply:

• the private key SHALL be generated in the secured environment to which the PKIoverheid PoR and the corresponding audit applies;
• the private key SHALL never be present unencrypted except in a Secure Cryptographic Device (SCD);
• the password necessary to make use of a private key SHALL be delivered in a manner such that the secrecy and integrity of the password is not compromised, to the
  • Applicant, when the Subject is a Natural Person, or
  • Applicant Representative, when the Subject is a Legal Entity.

Comment

This requirement expands on SDP-6.5.1-19 in ETSI EN 319 411-1.

6.1.2 Private key delivery to subscriber

No stipulation.

6.1.3 Public key delivery to certificate issuer

No stipulation.

6.1.4 CA public key delivery to relying parties

No stipulation.

6.1.5 Key sizes

Section 6.1.5 of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates SHALL apply, however, the NIST P-521 elliptic curve algorithm SHALL NOT be used.

Comment 1

The NIST P-521 elliptic curve algorithm is excluded because of stipulations in the Mozilla Root Store Policy (MRSP) section 5.1.

Comment 2

Although a TSP may not have to comply with the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates and/or the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates, certain sections will still by normative within PKIoverheid when explicitly mentioned in this PoR.

6.1.6 Public key parameters generation and quality checking

No stipulation.

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

No stipulation.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic module standards and controls

No stipulation.

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

No stipulation.

6.2.3 Private key escrow

Escrow by the TSP of a Subscriber’s Private Keys SHALL be allowed when all of the conditions below are met:

• the TSP has a written permission by the Subscriber, which can also be a Legal Representative or an Applicant Representative explicitly authorized for this purpose,
• the TSP CPS contains text on which parties are authorized to access the keys in escrow and under which conditions,
• the extensions:keyUsage field in the certificate has set
  • its dataEnciperment (3) bit, and
• the extensions:keyUsage field in the certificate has NOT set
  • its digitalSignature (0) bit, and/or
  • its nonRepudiation (1) bit.

Validation of identity of individuals authorized to access the keys in escrow SHALL be done using methods mentioned in Section 3.2.3, combined with methods mentioned in Section 3.2.5 in case of delegated authorization.

6.2.4 Private key backup

Back-up of the certificate holders’ private keys by the TSP is not allowed.

6.2.5 Private key archival

Archiving of the certificate holders’ private keys by the TSP is not allowed.

6.2.6 Private key transfer into or from a cryptographic module

No stipulation.

6.2.7 Private key storage on cryptographic module

The private keys used to sign

• Subscriber Certificates,
• Certificate Revocation Lists (CRL), and/or
• Online Certificate Status Protocol (OCSP) responses,

SHALL be generated, stored, and remain stored on a Hardware Security Module (HSM) which SHALL conform to the requirements in Section 6.2.11.

Comment

Hardware Security Modules (HSMs) can be network attached, PCI plug-in, smart card, or USB attached devices. These modules can be or contain eIDAS Qualified Signature Creation Devices (QSCDs) when certified as such.

6.2.8 Method of activating private key

No stipulation.

6.2.9 Method of deactivating private key

No stipulation.

6.2.10 Method of destroying private key

No stipulation.

6.2.11 Cryptographic Module Rating

No stipulation.

Comment 1

Assurance levels for Secure Cryptographic Devices (SCDs) holding the TSP’s private keys are described in ETSI EN 319 411-1 requirement OVR-6.2.5.2-01.

Comment 2

The rating of a Secure Cryptographic Devices (SCDs) containing or being eIDAS Qualified Signature Creation Devices (QSCDs) implies it is tested and certified by a party accredited to do so, to have attained Common Criteria (CC) Evaluation Assurance Level (EAL) 4+ using the Signature Activation Module (SAM) Protection Profile (PP) described in

• CEN-EN 419221-5 Protection Profiles for TSP Cryptographic Modules - Part 5: Cryptographic Module for Trust Services for local signing solutions, or
• CEN-EN 419241-2 Trustworthy Systems Supporting Server Signing - Part 2: Protection profile for QSCD for Server Signing for remote signing solutions.

6.3 Other aspects of key pair management

6.3.1 Public key archival

The TSP SHALL archive certificates containing any of the following keyPurposeId values

• szOID_KP_DOCUMENT_SIGNING (OID: 1.3.6.1.4.1.311.10.3.12),
• id-kp-documentSigning (OID: 1.3.6.1.5.5.7.3.36), and/or
• id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4),

in their extendedKeyUsage extension field, for at least seven years after their expiration.

Comment

ETSI stipulates an “appropriate period of time” for signature certificates. Before eIDAS was introduced, the Dutch Wet Elektronische Handtekeningen (WEH) stipulated seven years as an appropriate period. This requirement retains the period from the WEH.

6.3.2 Certificate operational periods and key pair usage periods

6.3.2.1 Certificate operational periods

Unless a more restrictive standard is applicable, issued certificates SHALL have a validity of no more than

• 3740 days when issued under the
  • G3 Autonomous Devices intermediate certificate, and
• 1915 days when issued under
  • any G3 (excluding G3 Autonomous Devices), or
  • any Private intermediate certificate, and
• 1185 days when issued under
  • any publicly trusted G4 intermediate certificate, or
  • any mandated trust G4 intermediate certificate, and
• 397 days when issued as a delegated OCSP Signing certificate,

unless it follows from legislative decree or directive a longer validity is needed for a specific use case.

If the latter is the case, the certificate

• SHALL have a validity of no more than is stated in the legislative decree or directive, and
• SHALL be issued either under a Private trust root, or an issuing certificate which is included in the EUTL, and

the TSP SHALL have been granted permission by the PA PKIoverheid for using PKIoverheid certificates for the specific use case.

Additionally, a certificate’s validity period SHALL NOT exceed the validity end date minus 1 day of its issuing certificate.

It is RECOMMENDED to use Short Lived Certificates for OCSP signing purposes.

Comment 1

For S/MIME certificates a more restrictive validity period is described in the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates by the CA/Browser Forum.

Comment 2

Certificate validity periods are colloquially referred to in years while grace periods in days. Therefore the following method is used for calculating validity periods:

• “10-year certificates”: 10x365 days + 90 days grace period = 3740 days
• “5-year certificates”: 5x365 days + 90 days grace period = 1915 days
• “3-year certificates”: 3x365 days + 90 days grace period = 1185 days

Used grace periods are in line with CA/Browser Forum practices.

Comment 3

An example of certificates with longer validity following from legislative decree are the certificates on Dutch taxi driver cards, which have a validity of no more than five years, as stated in the Dutch Passenger Transport Decree 2000, Article 83, paragraph 2. These need to issue Qualified signatures, as stated in the Dutch Directive Regulations on specifications and type approval of taxi on-board computer, Article 1.

6.3.2.2 Key pair usage periods

Re-use of a subject’s previously certified public key SHALL NOT be allowed when the corresponding certificate’s validity has ended, with the exception of usage within scope of ETSI EN 319 411-1 GEN-6.3.6-10 for certificates containing the keyPurposeId value szOID_EFS_CRYPTO (OID: 1.3.6.1.4.1.311.10.3.4) and/or id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4) in their profile’s extendedKeyUsage extension field.

6.4 Activation data

6.4.1 Activation data generation and installation

No stipulation.

6.4.2 Activation data protection

No stipulation.

6.4.3 Other aspects of activation data

No stipulation.

6.5 Computer security controls

6.5.1 Specific computer security technical requirements

The CA/Browser Forum Network and Certificate System Security Requirements (NetSec) document SHALL apply to the TSP’s certification systems, including the following amendment:

• the annual Penetration Test as described in NetSec Section 4 SHALL be more in-depth than the Vulnerability Scan mentioned in that same Section and SHALL be performed by an independent third party.

Comment

The PA PKIoverheid can decide to organize a Penetration Test for all PKIoverheid TSPs which can substitute the above annual Penetration Test if the TSP decides to participate.

6.5.2 Computer security rating

No stipulation.

6.6 Life cycle technical controls

6.6.1 System development controls

No stipulation.

6.6.2 Security management controls

No stipulation.

6.6.3 Life cycle security controls

No stipulation.

6.7 Network security controls

No stipulation.

6.8 Time-stamping

No stipulation.

7. CERTIFICATE, CRL, AND OCSP PROFILES

Comment

Both the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates and the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates are extensively referenced within this Section. Although not all TSPs need to comply with these baselines, certain sections will still be normative within PKIoverheid when explicitly mentioned in this PoR.

7.1 Certificate profile

Subscriber certificates SHALL NOT contain fields and extensions other than those described under this section.

Additionally, the TSP SHALL meet the technical requirements set forth in Section 2.2 Publication of Information, Section 6.1.5 Key Sizes, and Section 6.1.6 Public Key Parameters Generation and Quality Checking.

7.1.1 Version number(s)

Section 7.1.1 from the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates SHALL apply for all subscriber certificates.

7.1.2 Certificate content and extensions; Application of RFC 5280

7.1.2.1 Root CA Certificate

No stipulation.

Comment

Logius creates and manages the PKIo Root CA certificates. The practice for issuing and managing the PKIo Root certificates can be found in the PKIo CPS on the https://cps.pkioverheid.nl website.

7.1.2.2 Subordinate CA Certificate

No stipulation.

Comment

Logius creates two types of PKIo Subordinate CA certificates: the Intermediate Certificates, and the TSP Issuing Certificates which are issued to its TSPs. The practice for issuing the PKIo Subordinate CA certificates can be found in the PKIo CPS on the https://cps.pkioverheid.nl website.

7.1.2.3 Subscriber Certificate

7.1.2.3.1 version

See Section 7.1.1.

7.1.2.3.2 serialNumber

All subscriber certificates SHALL have a serialNumber field. This field SHALL have a value meeting the following requirements:

1. it SHALL be be greater than zero (0), and
2. it SHALL have a minimum length of 96 bits (12 octets), and
3. it SHALL contain at least 64 bits of data generated by a CSPRNG, and
4. it SHALL NOT be longer than 160 bits (20 octets), including a potential leading 0x00 of the DER-encoded value.

Comment 1

From these rules follow a minimum of 32 and a maximum of 95 bits which a TSP may use for its own purposes. This Let’s Encrypt post blog is a good source for more in-depth information on DER-encoded INTEGER values.

Comment 2

This section expands on requirements stipulated in the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates and Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates by the CA/Browser Forum.

7.1.2.3.3 signature

See Section 7.1.3.2.

7.1.2.3.4 issuer

See Section 7.1.4.1.

7.1.2.3.5 validity

All subscriber certificates SHALL contain the validity field.

For certificates containing the policyIdentifier value

• QCP-n-qscd (OID: 0.4.0.194112.1.2)
• QCP-l-qscd (OID: 0.4.0.194112.1.3), and/or
• NCP+ (0.4.0.2042.1.2),

in their extensions:certificatePolicies:extValue field, the value of the validity:notBefore sub-field SHALL be no more than 31 days after the certificate’s date and time of issuance, unless it follows from a legislative decree or directive a longer period is needed for a specific use case.

The validity:notBefore sub-field for all other certificates SHALL be the same as the certificate’s date and time of issuance.

The value of the validity:notAfter sub-field SHALL NOT be later than the maximum number of allowed days after the validity:notBefore date, as stipulated in Section 6.3.2.1.

Comment 1

Section 6.3.2.1 not only takes into account the theoretical maximum validity period, but also other factors like not having a validity date beyond the validity period of the issuing certificate.

Comment 2

Having a notBefore date in the future is useful for certificates on smart cards, when those smart cards are created in batches on specific days only, or when replacement smart cards can be ordered in advance. However, having a notBefore date too far in the future can enable sidestepping new requirements by issuing certificates with a notBefore date far in the future, just before a new requirement goes into effect. The 31 days stipulated in this requirement is arbitrarily chosen and is regarded as a sweet spot by the PKIoverheid PA.

Comment 3

An example of certificates with a longer period between the certificate issuance date and the validity:notBefore date following from legislative decree are the certificates on Dutch taxi driver cards. These can be requested three months in advance, as stipulated in the Dutch “Regulation of use of on-board computer and on-board computer cards” (in Dutch: “Regeling gebruik boordcomputer en boordcomputerkaarten”), Article 8, paragraph 5.

7.1.2.3.6 subject

See Section 7.1.4.2.2.

7.1.2.3.7 subjectPublicKeyInfo

See Section 7.1.3.1.

7.1.2.3.8 extensions:subjectKeyIdentifier

All subscriber certificates SHALL contain the extensions:subjectKeyIdentifier field, identified by OID 2.5.29.14.

The value of the extensions:subjectKeyIdentifier:critical field value SHALL be set to FALSE.

The value of the extensions:subjectKeyIdentifier:extValue field SHALL contain the SHA-1 hash of the subjectPublicKeyInfo:subjectPublicKey value.

7.1.2.3.9 extensions:keyUsage

All subscriber certificates SHALL contain the extension extensions:keyUsage field, identified by OID 2.5.29.15.

The extensions:keyUsage:critical value SHALL be set to TRUE.

The bit settings of the extensions:keyUsage:extValue field SHALL be identical to the value corresponding to the relevant subscriber certificate in the table below.

The extensions:keyUsage:extValue field SHALL NOT contain any additional bit settings.

7.1.2.3.10 extensions:subjectAltName

See Section 7.1.4.2.1.

7.1.2.3.11 extensions:basicConstraints

All subscriber certificates MAY contain the extension extensions:basicConstraints field, identified by OID 2.5.29.19.

The extensions:basicConstraints:critical field value SHALL be set to TRUE.

The extensions:basicConstraints:extValue field SHALL have its cA sub-field set to its DEFAULT value FALSE resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included.

Comment

ITU-T Recommendation X.690 (07/2002) on ASN.1 encoding rules states in Section 5.8: “The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value”. Stating in the description that “encoded certificates do NOT include the cA-subfield” therefore is redundant. However, in the past some TSPs employed CA-issuing software which did not do proper ASN.1 encoding resulting in a wrongfully included cA sub-field in encoded certificates. This encoding error resulted in some PKIX software rejecting these certificates. This redundant information therefore has to be regarded as a cautionary hint for TSPs to check their actual certificate encoding for these errors. Chances of this encoding bug still existing in ASN.1 encoding software are however slim since the last mention of such a bug on BugZilla is from 2016.

7.1.2.3.12 extensions:cRLDistributionPoints

All certificates SHALL contain the extension extensions:cRLDistributionPoints field, identified by OID 2.5.29.31.

The extensions:cRLDistributionPoints:critical value SHALL be set to FALSE.

The extensions:cRLDistributionPoints:extValue field SHALL contain one DistributionPoint.

The DistributionPoint SHALL contain the URI pointing to the CRL to be used for the certificate’s revocation status. The URI SHALL be accessible for all relying parties through usage of the HTTP protocol.

7.1.2.3.13 extensions:certificatePolicies

See Section 7.1.6.4.

7.1.2.3.14 extensions:authorityKeyIdentifier

All subscriber certificates SHALL contain the extension extensions:authorityKeyIdentifier field, identified by OID 2.5.29.35.

The extensions:authorityKeyIdentifier:critical value SHALL be set to FALSE.

The value of the extensions:authorityKeyIdentifier:extValue field SHALL contain the keyIdentifier [0] field with value the SHA-1 hash of the subjectPublicKeyInfo:subjectPublicKey value of the certificate’s issuing certificate in OCTET STRING notation.

7.1.2.3.15 extensions:extKeyUsage

All subscriber certificates SHALL contain the extension extensions:extKeyUsage field, identified by OID 2.5.29.37.

The extensions:extKeyUsage:critical value SHALL be set to FALSE.

The extensions:extKeyUsage:extValue field SHALL contain the KeyPurposeId value(s) as described in the table below.

Additionally, certificates with policies stated in the table below MAY contain the additional KeyPurposeId value of id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4).

The extensions:extKeyUsage:extValue field SHALL NOT contain any other KeyPurposeId values.

7.1.2.3.16 extensions:authorityInfoAccess

Subscriber certificates MAY contain the extensions:authorityInfoAccess field.

The extensions:authorityInfoAccess:critical value SHALL be set to FALSE.

The extensions:authorityInfoAccess:extValue field SHALL contain at least one of the AccessDescription fields described below, but MAY contain both.

• an AccessDescription with its accessMethod field set to identifier id-ad-ocsp (OID: 1.3.6.1.5.5.7.48.1) and its accessLocation field set to the HTTP URL of the issuing certificate’s OCSP responder;
• an AccessDescription with its accessMethod field set to identifier id-ad-caIssuers (OID: 1.3.6.1.5.5.7.48.2) and its accessLocation field set to the HTTP URL of the issuing certificate.

7.1.2.3.17 extensions:qcStatements

EU Qualified certificates SHALL contain the extensions:qcStatements field.

The extensions:qcStatements:critical field value SHALL be set to FALSE.

The extensions:qcStatements:extValue field SHALL contain the statementId Qualified Certificate Statements

• when the Subject is a natural person,
  • id-etsi-qcs-QcCompliance (OID: 0.4.0.1862.1.1),
  • id-etsi-qct-esign (OID: 0.4.0.1862.1.6.1),
  • id-etsi-qcs-QcSSCD (OID: 0.4.0.1862.1.4),
  • id-etsi-qcs-QcPDS (OID: 0.4.0.1862.1.5), and
• when the Subject is a Legal Entity,
  • id-qcs-pkixQCSyntax-v2 (OID: 1.3.6.1.5.5.7.11.2) with its semanticsIdentifier value set to id-etsi-qcs-SemanticsId-Legal (OID: 0.4.0.194121.1.2),
  • id-etsi-qcs-QcCompliance (OID: 0.4.0.1862.1.1),
  • id-etsi-qct-eseal (OID: 0.4.0.1862.1.6.2),
  • id-etsi-qcs-QcSSCD (OID: 0.4.0.1862.1.4), and
  • id-etsi-qcs-QcPDS (OID: 0.4.0.1862.1.5).

Certificates containing Qualified Certificate Statements with a statementId value of id-etsi-qcs-QcPDS (OID: 0.4.0.1862.1.5) SHALL have in its corresponding statementId field one PdsLocation with the URL to its PKI Disclosure Statement in IA5String format in its url sub-field, and its language as an ISO 639-1 language code (two-letter codes) in PrintableString format in its language sub-field.

7.1.2.4 CRL Signing Certificate

A Certificate Revocation List SHALL be signed by the same certificate which issued the subscriber certificates in scope of the applicable CRL. As such, no separate profile exists for CRL signing certificates.

7.1.2.5 Delegated OCSP Responder Certificate

7.1.2.5.1 version

Section 7.1.1 SHALL also apply to Delegated OCSP Responder Certificates.

7.1.2.5.2 serialNumber

Section 7.1.2.3.2 SHALL also apply to Delegated OCSP Responder Certificates.

7.1.2.5.3 signature

Section 7.1.3.2 SHALL also apply to Delegated OCSP Responder Certificates.

7.1.2.5.4 issuer

Section 7.1.4.1 SHALL also apply to Delegated OCSP Responder Certificates.

7.1.2.5.5 validity

All Delegated OCSP Responder certificates SHALL contain the validity field.

The value of the validity:notBefore sub-field SHALL be the certificate’s date and time of issuance.

The value of the validity:notAfter sub-field SHALL NOT be later than the maximum number of allowed days after the validity:notBefore date, as stipulated in Section 6.3.2.1.

7.1.2.5.6 subject

See Section 7.1.4.4.

7.1.2.5.7 subjectPublicKeyInfo

Section 7.1.3.1 SHALL also apply to Delegated OCSP Responder Certificates.

7.1.2.5.8 extensions:subjectKeyIdentifier

Section 7.1.2.3.8 SHALL also apply to Delegated OCSP Responder Certificates.

7.1.2.5.9 extensions:keyUsage

All Delegated OCSP Responder certificates SHALL contain the extension extensions:keyUsage field, identified by OID 2.5.29.15.

The extensions:keyUsage:critical value SHALL be set to TRUE.

The extensions:keyUsage:extvalue field SHALL have its digitalSignature bit set.

7.1.2.5.10 extensions:subjectAltName

See Section 7.1.4.4.

7.1.2.5.11 extensions:basicConstraints

Section 7.1.2.3.11 SHALL also apply to Delegated OCSP Responder Certificates.

7.1.2.5.12 extensions:cRLDistributionPoints

Delegated OCSP Responder certificates issued under the

• G3 Public Root,
• G1 Private Root, and/or
• G3 Trial Root,

MAY contain the extensions:cRLDistributionPoints field, identified by identifier 2.5.29.31.

Values of the extensions:cRLDistributionPoints field stipulated in Section 7.1.2.3.12 SHALL also apply to Delegated OCSP Responder Certificates.

Comment

In version 2.0.0 of the Baseline Requirements for TLS Server Certificates Ballot SC62v2 “Certificate profiles update” was introduced. This Ballot made extensions:cRLDistributionPoints a MUST NOT for OCSP Responders (see this commit). This does however introduce the risk of not being able to distrust the Delegated OCSP Responder certificate when it is revoked. Therefore, Short-Lived Certificates for Delegated OCSP Responder certificates are now recommended in section 6.3.2.1 “Certificate operational periods”. Usage under the G3-hierarchies is still allowed for backward compatibility only.

7.1.2.5.13 extensions:certificatePolicies

See Section 7.1.6.6.

7.1.2.5.14 extensions:authorityKeyIdentifier

Section 7.1.2.3.14 SHALL also apply to Delegated OCSP Responder Certificates.

7.1.2.5.15 extensions:extKeyUsage

All Delegated OCSP Responder certificates SHALL contain the extension extensions:extKeyUsage field, identified by OID 2.5.29.37.

The extensions:extKeyUsage:critical value SHALL be set to TRUE.

The extensions:extKeyUsage:extValue field SHALL contain the KeyPurposeId values id-kp-OCSPSigning (OID: 1.3.6.1.5.5.7.3.9).

The extensions:extKeyUsage:extValue field SHALL NOT contain any other KeyPurposeId values.

7.1.2.5.16 extensions:authorityInfoAccess

Delegated OCSP Responder certificates MAY contain the extensions:authorityInfoAccess field, identified by identifier 1.3.6.1.5.5.7.1.1.

The extensions:authorityInfoAccess:critical value SHALL be set to FALSE.

The extensions:authorityInfoAccess:extValue field SHALL contain an AccessDescription with its accessMethod field set to identifier id-ad-caIssuers (OID: 1.3.6.1.5.5.7.48.2) and its accessLocation field set to the HTTP URL of the issuing certificate.

7.1.2.5.17 extensions:qcStatements

Delegated OCSP Responder certificates SHOULD contain the extensions:qcStatements field.

The extensions:qcStatements:critical field value SHALL be set to FALSE.

The extensions:qcStatements:extValue field SHALL contain the id-qcs-pkixQCSyntax-v2 (OID: 1.3.6.1.5.5.7.11.2) Qualified Certificate statement with its semanticsIdentifier value set to id-etsi-qcs-SemanticsId-Legal (OID: 0.4.0.194121.1.2).

Comment

The id-qcs-pkixQCSyntax-v2 statement with its semanticsIdentifier value set to id-etsi-qcs-SemanticsId-Legal (OID: 0.4.0.194121.1.2) describes the semantics of the subject:organizationIdentifier field, as described in Section 5.1.4 of ETSI EN 319 412-1.

7.1.2.5.18 extensions:id-pkix-ocsp-nocheck

All Delegated OCSP Responder certificates SHALL contain the extension extensions:id-pkix-ocsp-nocheck field, identified by OID 1.3.6.1.5.5.7.48.1.5.

The extensions:extKeyUsage:critical value SHOULD be set to FALSE.

7.1.2.6 All Certificates

No stipulation.

7.1.2.7 Application of RFC 5280

No stipulation.

7.1.3 Algorithm object identifiers

Subscriber certificates SHALL NOT contain AlgorithmIdentifier values other than those described under this section.

7.1.3.1 subjectPublicKeyInfo

The subjectPublicKeyInfo field within a subscriber certificate SHALL contain in its subjectPublicKeyInfo:subjectPublicKey sub-field either an RSA key or an ECDSA key based on a P-256, or P-384 curve.

In case of an RSA key the subjectPublicKeyInfo:algorithmIdentifier field

1. SHALL contain rsaEncryption (OID: 1.2.840.113549.1.1.1), and
2. its parameters SHALL be present and SHALL be an explicit NULL.

When encoded, the AlgorithmIdentifier for RSA keys SHALL be byte-for-byte identical with the following hex-encoded bytes: 300d06092a864886f70d0101010500.

In case of an ECDSA key the subjectPublicKeyInfo:algorithmIdentifier field

1. SHALL contain the id-ecPublicKey (OID: 1.2.840.10045.2.1) algorithm identifier, and
2. its parameters SHALL be present and SHALL use the namedCurve encoding specifying one of the following curves:
   1. secp256r1 (OID: 1.2.840.10045.3.1.7) for P-256 keys, or
   2. secp384r1 (OID: 1.3.132.0.34) for P-384 keys.

When encoded, the subjectPublicKeyInfo:algorithmIdentifier field for ECDSA keys SHALL be byte-for-byte identical with the following hex-encoded bytes:

• for P-256 keys, 301306072a8648ce3d020106082a8648ce3d030107, and
• for P-384 keys, 301006072a8648ce3d020106052b81040022.

Comment

Usage of Elliptic Curves in PKI keys makes most sense for server certificates on high traffic websites, conforming to requirements for public trusted roots is the most obvious consideration in algorithm choice. Although Elliptic Curves P-256, P-384, and P-512 are allowed according to the CA/Browser forum, the Mozilla Root Store Policy only allowes P-256 and P-384. Because PKIoverheid aspires broad compatibility it has chosen to only allow P-256 and P-384 curves. However, these curves are known to have theoretical weaknesses. More information on these weaknesses can be found on https://safecurves.cr.yp.to/. It is up to a subscriber to decide if the Elliptic Curve performance boost outweighs the theoretical security risk for their use case. Browser vendors are of the opinion it is safe enough for their user base.

7.1.3.2 Signature AlgorithmIdentifier

All objects signed by a TSP PKIo Private Key SHALL conform to these requirements on the use of the AlgorithmIdentifier or AlgorithmIdentifier-derived type in the context of signatures. In particular, it applies to all of the following objects and fields:

• the signatureAlgorithm field of a Certificate or Precertificate;
• the signature field of a TBSCertificate;
• the signatureAlgorithm field of a CertificateList;
• the signature field of a TBSCertList;
• the signatureAlgorithm field of a BasicOCSPResponse.

The TSP SHALL use one of the following signature algorithms and encodings. When encoded, the AlgorithmIdentifier SHALL be byte-for-byte identical with the specified hex-encoded bytes.

• RSASSA-PKCS1-v1_5 with SHA-256, encoded into: 300d06092a864886f70d01010b0500.
• RSASSA-PKCS1-v1_5 with SHA-384, encoded into: 300d06092a864886f70d01010c0500.
• ECDSA with SHA-256, encoded into: 300a06082a8648ce3d040302;
• ECDSA with SHA-384, encoded into: 300a06082a8648ce3d040303.

Comment

Although theoretically allowed, using ECDSA signatures by the TSPs is currently not possible since currently all issuing CAs use RSA keys.

7.1.4 Name forms

PKIo certificates SHALL contain name forms only in its issuer and subject fields.

7.1.4.1 Issuer Information

For each issued PKIo certificate, the encoded content of the Issuer Distinguished Name (IDN) field SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name (SDN) field of the Issuing TSP certificate.

7.1.4.2 Subject Information – Subscriber Certificates

For each PKIo subscriber certificate all the following general rules apply to Subject attributes:

1. the encoded content of the Subject Distinguished Name (SDN) field of a certificate SHALL be byte-for-byte identical among all certificates (including expired and revoked ones) whose SDN can be compared as being equal;
2. subject attributes SHALL NOT contain only metadata such as ‘.’, ‘-’, and ’ ’ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.

7.1.4.2.1 Subject Alternative Name Extension Fields

Subscriber certificates either SHALL or MAY contain the extensions:subjectAltName field, identified by OID 2.5.29.17, depending on requirements described in the following sub-sections. Certificates SHALL NOT contain any extensions:subjectAltName fields other than those described.

The extensions:subjectAltName:critical value SHALL be set to FALSE.

The extensions:subjectAltName:extValue field contains a sequence of one or more GeneralName attributes, whose types depend on the requirements described in the following sub-sections.

7.1.4.2.1.1 extensions:subjectAltName:dNSName

Certificates containing the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) EKU MAY contain the extensions:subjectAltName extension having at least one instance of the dNSName attribute in its extValue field.

Each dNSName attribute SHALL contain a Fully-Qualified Domain Name (FQDN).

The FQDN SHALL:

• be in the “preferred name syntax”, as specified in RFC 5280, and
• be owned or controlled by the Subject and to be associated with the Subject’s server which MAY be owned and operated by the Subject or another entity (e.g., a hosting service), the verification of which is described in Section 3.2.5.

Additionally, the FQDN SHALL NOT:

• contain a wildcard, and/or
• be an Internal Name.

The total number of instances of the dNSName attribute in a single certificate SHALL NOT:

• exceed 10 when these instances consist of one Base Domain Name and sub-domains thereof, or
• exceed 5 when these instances consist of multiple Base Domain Names.

7.1.4.2.1.2 extensions:subjectAltName:iPAddress

Certificates containing the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) EKU when issued under the

• G1 Private root, or
• G3 Trial root,

MAY contain an iPAddress attribute instance in its extensions:subjectAltName:extValue field.

The total number of iPAddress attribute instances in a certificate SHALL NOT exceed five.

Each iPAddress attribute instance SHALL contain an IP address.

This IP address SHALL:

• be in the syntax as specified in RFC 5280, and
• be controlled by the Subject or has been authorized for use by the IP address assignee, the verification of which is described in Section 3.2.5.

Additionally, this IP address SHALL NOT be a Reserved IP Address.

Comment

All Reserved IP Addresses can be found on the IANA website:

• IANA IPv4 Special-Purpose Address Registry
• IANA IPv6 Special-Purpose Address Registry

7.1.4.2.1.3 extensions:subjectAltName:otherName

Certificates which DO NOT contain S/MIME policy identifier

• Organization-validated Strict (OID: 2.23.140.1.5.2.3),
• Sponsor-validated Strict (OID: 2.23.140.1.5.3.3), or
• Individual-validated Strict (OID: 2.23.140.1.5.4.3),

MAY contain the extensions:subjectAltName extension with one or more otherName attributes in its extValue field.

An otherName attribute is an object consisting out of a sequence of a type-id field and a value field. Each otherName attribute SHALL contain a value to identify the subject for which the other permitted subject attributes do not qualify.

The type-id field of an otherName attribute SHALL contain one of the following OIDs:

• Microsoft User Principal Name (MSUPN) (OID: 1.3.6.1.4.1.311.20.2.3), or
• IA5String (OID: 1.3.6.1.4.1.1466.115.121.1.26) but MAY also be 2.5.5.5, or
• Permanent Identifier (OID: 1.3.6.1.5.5.7.8.3).

In the otherName attribute the value field contents depends on the value in its type-id field:

• In the otherName attribute the value field related to the type-id field with value Microsoft User Principal Name (MSUPN)
  • SHALL be encoded in UTF8, and
  • SHALL use syntax ‘<UPN-prefix>@<UPN-suffix>’.
• In the otherName attribute the value field related to the type-id field with value IA5String
  • SHALL be encoded in ISO 646 (IA5), and
  • SHALL use syntax ‘<Assigner-OID>-<Subject-string>’.
• In the otherName attribute the value field related to the type-id field with value PermanentIdentifier SHALL consist out of both an identifierValue and an assigner field, of which
  • the PermanentIdentifier:identifierValue field
    • SHALL be encoded in UTF8, and
    • SHALL use syntax ‘<Subject-string>’, and
  • the PermanentIdentifier:assigner field SHALL contain ‘<Assigner-OID>’.

The <UPN-suffix> is EITHER

• a DNS domain name which SHALL be validated using the methods which also apply for the extensions:subjectAltName:dNSName attribute, OR
• an identifier which can be used to map against a Microsoft Active Directory Domain, the source of which SHALL be formally authorized by the PKIoverheid PA as a qualified source for this usage.

The <Assigner-OID> is an Object Identifier which EITHER

• is described in the PKIo-arc OID document and consists out of an PKIoverheid OID-arc number which
  • SHALL be assigned to the TSP by the PKIo PA specifically for this usage, and
  • SHALL be documented in the TSP CPS, and
  • MAY be expanded by a persistent number chosen by the TSP to specify its identification mechanism, OR
• is outside of the PKIoverheid OID-arc but SHALL be formally authorized by the PKIoverheid PA as a qualified source for this usage.

The <UPN-prefix> consists out of a value which

• SHALL be assigned by
  • an assigner mentioned in the PKIoverheid OID-arc, or
  • an assigner formally authorized by the PKIoverheid PA as a qualified source for this usage, and
• SHALL conform to a naming scheme described in the TSP CPS.

The <Subject-string> consists out of a value which

• SHALL conform to a naming scheme described in the TSP CPS, and
• when assigned by an <Assigner-OID> within the PKIoverheid OID-arc,
  • SHALL qualify to be regarded as to uniquely and permanently identify the subject (not always possible to guarantee when a third party is responsible for part of the <Subject-string>), and
• when not assigned by an <Assigner-OID> within the PKIoverheid OID-arc,
  • SHALL contain a subject identifying string which adheres to the naming scheme defined by the assigner.

Comment 1

Normally the otherName attribute of type Microsoft User Principal Name (MSUPN) is used for Single Sign-On (SSO) purposes in Windows environments. However, since publication of Microsoft Knowledge Base article KB5014754: Certificate-based authentication changes on Windows domain controllers usage of the MSUPN for SSO mapping purposes is considered weak. Usage therefore will eventually be deprecated.

Comment 2

The otherName type Permanent Identifier (OID: 1.3.6.1.5.5.7.8.3) is defined in RFC 4043.

7.1.4.2.1.4 extensions:subjectAltName:rfc822Name

Certificates issued under root certificate

• G3 Public,
• G1 Private, or
• G3 Trial,

and which do NOT contain S/MIME policy identifier

• Organization-validated Strict (OID: 2.23.140.1.5.2.3),
• Sponsor-validated Strict (OID: 2.23.140.1.5.3.3), or
• Individual-validated Strict (OID: 2.23.140.1.5.4.3),

MAY contain the extensions:subjectAltName extension with any rfc822Name attributes in its extValue field.

Certificates containing S/MIME policy identifier

• Organization-validated Strict (OID: 2.23.140.1.5.2.3),
• Sponsor-validated Strict (OID: 2.23.140.1.5.3.3), or
• Individual-validated Strict (OID: 2.23.140.1.5.4.3),

SHALL contain the extensions:subjectAltName extension with one or more rfc822Name attributes in its extValue field.

Each rfc822Name attribute SHALL contain a value which:

• is in the “Mailbox” format as specified in RFC 822, and
• is controlled by the Subject, the verification of which is described in Section 3.2.5.

7.1.4.2.2 Subject Distinguished Name Fields

Certificates SHALL NOT contain any Subject Distinguished Name (SDN) fields other than those described in the following sub-sections.

7.1.4.2.2.1 subject:commonName (OID: 2.5.4.3)

Certificates containing the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) EKU SHOULD NOT contain the subject:commonName field.

All other certificates SHALL contain the subject:commonName field.

Values of the subject:commonName field vary based on the certificate policy:

• the value of the subject:commonName field in certificates mentioned in the list below

  • all Sponsor-validated certificates under the G3 Public, G1 Private, and G3 Trial roots, excluding certificates containing the S/MIME Sponsor-validated Strict certificate policy (OID: 2.23.140.1.5.3.3),
  • all Individual-validated certificates under the G3 Public, G1 Private, and G3 Trial roots, excluding certificates containing the S/MIME Individual-validated Strict certificate policy (OID: 2.23.140.1.5.4.3),

  SHALL be in either one of the following two formats, the components of which SHALL be validated using appropriate validation methods mentioned in Section 4, excluding nickname:

  • [aristocratic designation] [Full first forename OR nickname] [initials other forenames OR full other forenames] [surname prefixes + surname partner ‘-’] [aristocratic title] [surname prefixes + surname at birth]
  • [aristocratic designation] [surname prefixes + surname partner ‘-’] [Full first forename OR nickname] [initials other forenames OR full other forenames] [aristocratic title] [surname prefixes + surname at birth],

  whereby:

  • text in bold = SHALL be used, and style SHALL be in accordance with the used legal identification document,
  • text in italic = SHALL be used, with choice from full forenames or initials, and
  • normal text = MAY be used; if present, the style SHALL be the same as in the used legal identification document, and the use of nickname is NOT RECOMMENDED;

• the value of the subject:commonName field in

  • certificates issued under the G3 Public root containing either the S/MIME Sponsor-validated Strict certificate policy (OID: 2.23.140.1.5.3.3), or the S/MIME Individual-validated Strict certificate policy (OID: 2.23.140.1.5.4.3), and
  • certificates issued under any G4 Natural Persons intermediate certificate

  SHALL contain the personal name of the Subject which SHOULD be presented as subject:givenName followed by subject:surname. The personal name MAY be in the Subject’s preferred presentation format or a format preferred by the TSP, but SHALL be a meaningful representation of the Subject’s name as verified under Section 3.2.3.

• the value of the subject:commonName field in

  • Organization-validated certificates issued under the G3 Public root containing the S/MIME Organization-validated Strict certificate policy (OID: 2.23.140.1.5.2.3), and
  • Organization-validated certificates issued under any G4 S/MIME root,

  SHALL be byte-for-byte identical to the subject:organizationName value.

• the value of the subject:commonName field in

  • Organization-validated certificates issued under the G3 Public root NOT containing the S/MIME Organization-validated Strict certificate policy (OID: 2.23.140.1.5.2.3), and
  • all certificates issued under any G4 Non-S/MIME root,

  SHALL contain:

  • the function of an organizational entity, or
  • a copy of the subject:organizationName field;

• the value of the subject:commonName field in Device-validated certificates NOT containing the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) EKU SHALL contain a device number or device type number, the authoritative source of which SHALL be described in the TSP CPS;

• the value of the subject:commonName field in certificates containing the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) EKU SHALL contain

  • the function or name of an organizational entity, or
  • the name by which the service, device or system is known, which SHALL be
    • a Fully-Qualified Domain Name (FQDN) which SHALL be one of the values contained in the dNSNAme attribute of the Certificate’s subjectAltName extension (see Section 7.1.4.2.1) and which SHALL NOT be in U-label encoding, or
    • a local domain name which SHALL NOT be in U-label encoding, or
    • a local host name which SHALL NOT be in U-label encoding, or
    • a local IP address which SHALL be one of the values contained in the iPAddress attribute of the Certificate’s subjectAltName extension (see Section 7.1.4.2.1).

If values exceed the maximum subject:commonName field length of 64 characters, they SHALL be cut off after the maximum number of characters allowed.

Comment 1

ETSI EN 319 412-2 Section 4.2.4 states: “The commonName attribute value shall contain a name of the subject. This may be in the subject’s preferred presentation format, or a format preferred by the CA, or some other format. Pseudonyms, nicknames, and names with spelling other than defined by the registered name may be used. NOTE 1: The commonName attribute has a usage purpose that is different from the required choice of pseudonym or givenName/surname. The commonName attribute is used for user friendly representation of the person’s name, whereas givenName/surname is used where more formal representation or verification of specific identity of the user is required. To maximize interoperability both are considered necessary.”

Comment 2

More information on U-labels can be found in RFC 5891. This RFC defines the revised protocol definition for Internationalized Domain Names (IDNs), specifying the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. A domain name consists of a sequence of labels, conventionally written separated by dots. An IDN is a domain name that contains one or more labels that, in turn, contain one or more non-ASCII characters. Valid labels can be in either “U-label”, “A-label”, or “NR-LDH label” form, with the appropriate one determined by particular protocols or by context. U-label form is a direct representation of the Unicode characters using UTF-8, UTF-16, or UTF-32.

7.1.4.2.2.2 subject:surname (OID: 2.5.4.4)

Certificates issued to natural persons SHALL contain the subject:surname field.

The value of the subject:surname field SHALL contain the surname as can be found in a legally binding document proving the subject’s identity verified under Section 3.2.3. The value SHALL NOT contain any NULL characters.

If the surname length exceeds the maximum subject:surname field length it SHALL be cut off after the maximum number of characters allowed.

Comment

In Dutch law the Compulsory Identification Act (“Wet op de identificatieplicht” in Dutch) describes all legally binding documents which can be used to prove a person’s identity.

7.1.4.2.2.3 subject:serialNumber (OID: 2.5.4.5)

Certificates issued to natural persons SHALL contain the subject:serialNumber field.

Certificates issued to Legal Entities MAY contain the subject:serialNumber field.

The value of the subject:serialNumber field SHALL SHALL uniquely identify the subject.

Values of the subject:serialNumber field SHALL NOT contain exactly 20 characters, except when used for OIN/HRN identifiers (where allowed).

7.1.4.2.2.4 subject:countryName (OID: 2.5.4.6)

All certificates SHALL contain the subject:countryName field.

The subject:countryName attribute in certificates in which the Subscriber is a natural person SHALL contain the name of a country which specifies a general context in which other attributes are to be understood. The TSP CPS SHALL unambiguously describe how this value is to be understood.

The subject:countryName attribute in certificates in which the Subscriber is a Legal Entity SHALL specify the country in which the Legal Entity is established.

The country value in the subject:countryName attribute SHALL be in the two-letter ISO 3166-1 country code notation. If a country is not represented by an official ISO 3166-1 country code, the TSP SHALL use code XX.

Comment

ETSI EN 319 412-2 requirement NAT-4.2.4-1 states the countryName attribute is mandatory. The meaning of this attribute however, can be very broad, as stipulated in requirement NAT-4.2.4-8: “The countryName attribute value specifies a general context in which other attributes are to be understood. The verifier may have to consult the certificate policy of the issuer to determine the exact semantics of this attribute.” This means the trustworthiness of transactions using these certificates depends on both ETSI and CPS knowledge at relying parties, which in practice can not always be relied upon. Many parties will assume a country of residence or nationality, but this attribute can be many other things as well. Because of this the PA PKIoverheid recommends using this field for obvious uses only. Outside of specific sectoral use cases, the most obvious context will probably be nationality, since place of residence will be difficult to validate for non-governmental agencies.

7.1.4.2.2.5 subject:localityName (OID: 2.5.4.7)

Certificates issued under root certificate

• G3 Public,
• G1 Private, or
• G3 Trial,

MAY contain the subject:localityName field.

The subject:localityName attribute in certificates in which the Subscriber is a natural person SHALL contain the name of a locality which specifies a general context in which other attributes are to be understood. The TSP CPS SHALL unambiguously describe how this value is to be understood.

The subject:localityName attribute in certificates in which the Subscriber is a Legal Entity SHALL specify the locality in which the Legal Entity is established.

7.1.4.2.2.6 subject:stateOrProvinceName (OID: 2.5.4.8)

Certificates issued under root certificate

• G3 Public,
• G1 Private, or
• G3 Trial,

MAY contain the subject:stateOrProvinceName field.

The subject:stateOrProvinceName attribute in certificates in which the Subscriber is a natural person SHALL contain the name of a state or province which specifies a general context in which other attributes are to be understood. The TSP CPS SHALL unambiguously describe how this value is to be understood.

The subject:stateOrProvinceName attribute in certificates in which the Subscriber is a Legal Entity SHALL specify the state or province in which the Legal Entity is established.

7.1.4.2.2.7 subject:organizationName (OID: 2.5.4.10)

Certificates in which the Subscriber is a Legal Entity SHALL contain the subject:organizationName field.

The value of the subject:organizationName field SHALL be the full name of the Subscriber, as verified under Section 3.2. Only for Device-validated certificates containing certificate policies mentioned in the table below, this MAY be the organization with which the TSP has entered into an agreement for the linkage/award of certificates to devices, as stipulated in a framework of standards.

If the assumed subject:organizationName field value exceeds 64 characters, the TSP SHALL only issue the certificate when:

1. parts of the organization name are abbreviated, and/or non-material words are omitted in the organization name in such a way that the assumed value no longer exceeds the 64-character limit, and
2. a Relying Party will not be misled into thinking that they are dealing with a different organization, and
3. the subscriber agrees with the chosen abbreviation in written form.

7.1.4.2.2.8 subject:organizationalUnitName (OID: 2.5.4.12)

Certificates,

• in which the Subscriber is a Legal Entity, and
• which are issued under root certificate
  • G3 Public,
  • G1 Private, or
  • G3 Trial,

MAY contain the subject:organizationalUnitName attribute.

The value of the subject:organizationalUnitName attribute SHALL specify an identifier of an organizational entity, the validation of which SHALL be described in the CPS of the TSP. This value SHALL NOT resemble functional roles or titles.

Comment 1

The identifier of an organizational entity can be in any form, i.e. name, number, or a combination of both.

Comment 2

Usage of the subject:organizationalUnitName attribute is discouraged because it is inherently impossible to verify through independent reliable sources. Therefore PKIoverheid only allows this attribute for legacy purposes, meaning the G3 and G1 Private hierarchies.

7.1.4.2.2.9 subject:title (OID: 2.5.4.12)

Certificates,

• issued to a natural person or an autonomous device, and
• which are issued under root certificate
  • G3 Public,
  • G1 Private, or
  • G3 Trial,

MAY contain the subject:title field.

Certificates issued under a G4 root and categorized as a Regulated Profession certificate in Section 7.1.6.1 Reserved “Certificate Policy Identifiers” SHALL contain the subject:title field.

The value of the subject:title field SHALL

• when issued to an autonomous device under the G3 Public root, be an attribute describing the authorization of the (autonomous) device according to a framework of standards, as verified by means which SHALL be described in the TSP CPS, and
• in all other certificate types, be the professional title as verified under Section 3.2.5.3.

7.1.4.2.2.10 subject:organizationIdentifier (OID: 2.5.4.97)

Certificates issued to

• Legal Entities, or
• Sponsor-validated natural persons AND containing the id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4) EKU,

SHALL contain the subject:organizationIdentifier attribute.

Certificates issued to

• Sponsor-validated natural persons and NOT containing the id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4) EKU,

MAY contain the subject:organizationIdentifier attribute.

The value of the subject:organizationIdentifier field in certificates issued to Legal Entities or Sponsor-validated natural persons containing the id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4) EKU, SHALL contain EITHER:

• an identifier conforming to the semantics for legal person identifiers set forth in Section 5.1.4 of ETSI standard EN 319 412-1, or
• an OIN/HRN number.

The value of the subject:organizationIdentifier field in certificates issue to Sponsor-validated natural persons without the id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4) EKU, SHALL contain

• an identifier conforming to the semantics for legal person identifiers set forth in Section 5.1.4 of ETSI standard EN 319 412-1.

Comment 1

TSPs wanting to use a register for legal person identifiers which could qualify as a “national scheme” as described in ETSI standard EN 319 412-1 Section 5.1.4 can apply at Logius for a two-character encoding identifying the relevant source. These encodings will be added to the PKIo CPS.

Comment 2

OIN/HRN identifiers adhering to the “national scheme” clause in Section 5.1.4 of ETSI standard EN 319 412-1 are preferred from a standards perspective. However, this is an unlikely scenario for the foreseeable future since

1. no “national scheme” has been described as of yet,
2. it is unclear who is or should be responsible for such a scheme, and
3. many governmental systems will have to be updated to be able to parse the new semantics.

7.1.4.2.2.11 subject:givenName (OID: 2.5.4.42)

Certificates issued to a natural person SHALL contain the subject:givenName field.

The value of the subject:givenName field SHALL contain the given name(s) as can be found in a legally binding document proving the subject’s identity verified under Section 3.2.3.

Comment

In Dutch law the Compulsory Identification Act (“Wet op de identificatieplicht” in Dutch) describes all legally binding documents which can be used to prove a person’s identity.

7.1.4.3 Subject Information – Root Certificates and Subordinate CA Certificates

Not applicable for PKIoverheid TSP services.

7.1.4.4 Subject Information – Delegated OCSP Responder Certificates

Delegated OCSP Responder Certificates SHALL have their encoded subject and any encoded extensions:subjectAltName fields byte-for-byte identical to the same fields in their issuing certificates with the exception of only the subject:commonName field.

The Subject Distinguished Name (SDN) field of a Delegated OCSP Responder Certificate SHALL be byte-for-byte identical with the encoded form of its Issuer Distinguished Name (IDN) field, with the exception of only the subject:commonName field.

The subject:commonName field SHALL contain the issuer:commonName concatenated with an identifier indicating usage for Delegated OCSP Responder purposes. If this results in a value exceeding 64 characters, part(s) of the value SHALL be abbreviated in a sensible manner.

Delegated OCSP Responder Certificates issued under

• G3 Public Intermediate certificates NOT containing any S/MIME Strict certificate policy identifiers (OID: 2.23.140.1.5.2.3, 2.23.140.1.5.3.3, or 2.23.140.1.5.4.3),
• G1 Private Intermediate certificates, and/or
• G3 Trial Intermediate certificates,

MAY contain a extensions:subjectAltName field. This value of this field SHALL be byte-for-byte identical with the encoded form of its extensions:issuerAltName field.

Comment

The CA/Browser Forum TLS Baseline Requirements does not allow the extensions:subjectAltName field for Delegated OCSP Responder Certificates. However, in previous versions of this Programme of Requirements this field was mandatory. Therefore, this field is allowed for backwards compatibility in G3 and G1 Private roots only.

7.1.5 Name constraints

No stipulation.

7.1.6 Certificate policy object identifier

Comment

Logius creates and manages the PKIo Root and Intermediate certificates, and signs the TSP issuing certificates. Information on certificate policy object identifiers for these certificates can therefore be found in the PKIo CPS on the cps.pkioverheid.nl website.

7.1.6.1 Reserved Certificate Policy Identifiers

Policy identifiers set forth in the table below are reserved for usage in PKIo certificates.

Comment

The Certificate Policy identifiers reserved for use by PKIoverheid TSPs can be found in the “PKIoverheid specific OIDs” document which can be found on oid.pkioverheid.nl.

7.1.6.2 Root CA Certificates

No stipulation.

Comment

Logius creates and manages the PKIo Root CA certificates. The practice for issuing and managing the PKIo Root certificates can be found in the PKIo CPS on cps.pkioverheid.nl.

7.1.6.3 Subordinate CA Certificates

No stipulation.

Comment

Logius creates two types of PKIo Subordinate CA certificates: the Intermediate Certificates, and the TSP Issuing Certificates which are issued to its TSPs. The practice for issuing the PKIo Subordinate CA certificates can be found in the PKIo CPS on cps.pkioverheid.nl.

7.1.6.4 Subscriber Certificates

All subscriber certificates SHALL contain the extensions:certificatePolicies field, identified by OID 2.5.29.32.

The extensions:certificatePolicies:critical field value SHALL be set to FALSE.

The extensions:certificatePolicies:extValue field

• SHALL contain
  • the policyIdentifier field containing
    • the OID matching the relevant certificate type from the table in Section 7.1.6.1 “Reserved Certificate Policy Identifiers”, and
    • the ETSI NCP+ OID of 0.4.0.2042.1.2 for certificates issued under a G4 root when the TSP provisions the secure crytographic device (SCD) for the subject, and
    • the ETSI QCP-n-qscd OID of 0.4.0.194112.1.2 for EU Qualified certificates issued to natural persons under a G4 root, and
    • the ETSI QCP-l-qscd OID of 0.4.0.194112.1.3 for EU Qualified certificates issued to Legal entities under a G4 root, and
    • the CA/Browser Forum S/MIME Individual Validated (Legacy) OID of 2.23.140.1.5.4.1 for certificates issued under the G3 Legacy Citizen intermediate certificate and containing the emailProtection EKU, and
    • the CA/Browser Forum S/MIME Sponsor Validated (Legacy) OID of 2.23.140.1.5.3.1 for certificates issued under the G3 Legacy Organization Persons intermediate certificate and containing the emailProtection EKU, and
    • the CA/Browser Forum S/MIME Organization Validated (Legacy) OID of 2.23.140.1.5.2.1 for certificates issued under the G3 Legacy Organization Services or G3 Autonomous Devices intermediate certificate and containing the emailProtection EKU, and
    • the CA/Browser Forum S/MIME Individual Validated (Strict) OID of 2.23.140.1.5.4.3 for Individual-validated S/MIME certificates issued under
      • the G3 2023 S/MIME Intermediate certificate, or
      • the G4 S/MIME Root certificate, and
    • the CA/Browser Forum S/MIME Sponsor Validated (Strict) OID of 2.23.140.1.5.3.3 for Sponsor-validated S/MIME certificates issued under
      • the G3 2023 S/MIME Intermediate certificate, or
      • the G4 S/MIME Root certificate, and
    • the CA/Browser Forum S/MIME Organization Validated (Strict) OID of 2.23.140.1.5.2.3 for Organization-validated S/MIME certificates issued under
      • the G3 2023 S/MIME Intermediate certificate, or
      • the G4 S/MIME Root certificate, and
  • the policyQualifiers:policyQualifierId field with value id-qt-cps 1.3.6.1.5.5.7.2.1 (RFC 5280), and
  • the policyQualifiers:qualifier:cPSuri field with the HTTPS URL for the TSPs Certification Practice Statement (CPS) as value, and
• SHOULD contain
  • the policyIdentifier field containing
    • the ETSI NCP+ OID of 0.4.0.2042.1.2 for certificates when the TSP provisions the secure crytographic device (SCD) for the subject, and issued under
      • the G3 Public Root certificate,
      • the G1 Private Root certificate, or
      • the G3 Trial root certificate, and
    • the ETSI QCP-n-qscd OID of 0.4.0.194112.1.2 for certificates issued to natural persons and containing the nonRepudiation bit in its keyUsage field, and issued under
      • the G3 Public Root certificate,
      • the G1 Private Root certificate, or
      • the G3 Trial root certificate, and
    • the ETSI QCP-l-qscd OID of 0.4.0.194112.1.3 for certificates issued to Legal Entities and containing the nonRepudiation bit in its keyUsage field, and issued under
      • the G3 Public Root certificate,
      • the G1 Private Root certificate, or
      • the G3 Trial root certificate, and
• MAY contain
  • the policyQualifiers:qualifier field containing the userNotice field.

The extensions:certificatePolicies:policyQualifiers:userNotice value SHOULD be encoded in UTF8String, but MAY be encoded in IA5String.

7.1.6.5 CRL Signing Certificate

No stipulation.

7.1.6.6 Delegated OCSP Responder Certificates

All Delegated OCSP Responder Certificates SHALL contain the extensions:certificatePolicies field, identified by OID (OID: 2.5.29.32).

The extensions:certificatePolicies:critical field value SHALL be set to FALSE.

The extensions:certificatePolicies:extValue field SHALL contain the

1. OID matching the relevant certificate type from the table in Section “7.1.6.1 Reserved Certificate Policy Identifiers”, and
2. the policyQualifiers:policyQualifierId field with value id-qt-cps (OID: 1.3.6.1.5.5.7.2.1), and
3. the policyQualifiers:qualifier:cPSuri field with the HTTPS URL for the TSP’s Certification Practice Statement as value.

The extensions:certificatePolicies:extValue field SHALL contain the ETSI NCP+ OID of 0.4.0.2042.1.2.

The extensions:certificatePolicies:extValue field MAY contain the policyQualifiers:qualifier:userNotice field.

The extensions:certificatePolicies:policyQualifiers:userNotice value SHOULD be encoded in UTF8String, but MAY be encoded in IA5String.

Comment 1

Since the private keys of Delegated OCSP Responder Certificates reside on an HSM (see Section 6.2.7 “Private key storage on cryptographic module”), the ETSI NCP+ policy identifier needs to be present in Delegated OCSP Responder Certificates.

Comment 2

The id-qt-cps policy is described in RFC 5280.

7.1.7 Usage of Policy Constraints extension

No stipulation.

7.1.8 Policy qualifiers syntax and semantics

No stipulation.

7.1.9 Processing semantics for the critical Certificate Policies extension

No stipulation.

7.2 CRL profile

The tbsCertList field in PKIo Certificate Revocation Lists SHALL NOT contain fields and extensions other than those described under this section.

The signatureAlgorithm field in PKIo Certificate Revocation Lists SHALL comply with the stipulations in Section 7.1.3.2.

7.2.1 Version number(s)

The Version field in PKIo Certificate Revocation Lists SHALL specify version 2 (the integer value is 1).

7.2.2 CRL and CRL entry extensions

PKIo Certificate Revocation Lists (CRL) SHALL contain the extension values in the Extensions fields described in the sub-sections of this Section.

7.2.2.1 tbsCertList:crlExtensions

The tbsCertList:crlExtensions field SHALL be present in PKIo Certificate Revocation Lists and SHALL contain an Extensions field.

The tbsCertList:crlExtensions:Extensions field

1. SHALL contain the extension fields:
   1. AuthorityKeyIdentifier (OID: 2.5.29.35), and
   2. CRLNumber (OID: 2.5.29.20), and
   3. expiredCertsOnCRL (OID: 2.5.29.60) if the CRL contains expired certificates at the time found in the tbsCertList:thisUpdate field, and
2. MAY contain the extension field:
   1. AuthorityInfoAccessSyntax (OID: 1.3.6.1.5.5.7.1.1).

All extension critical and extValue fields SHALL have values compliant with RFC 5280, and in the case of the extension expiredCertsOnCRL with ISO IEC 9594-8.

Comments

The rationale on authorityKeyIdentifier extension field usage can be found in IETF RFC 5280 Section 5.2.1 stating “Conforming CRL issuers MUST use the key identifier method, and MUST include this extension in all CRLs issued”.

7.2.2.2 tbsCertList:revokedCertificates:crlEntryExtensions:Extensions

PKIo Certificate Revocation Lists (CRL) SHALL contain the tbsCertList:revokedCertificates:crlEntryExtensions:Extensions field.

The tbsCertList:crlExtensions:Extensions field

1. MAY contain the Extension field
   1. CRLReason (OID: 2.5.29.21), and
   2. InvalidityDate (OID: 2.5.29.24), and
2. SHOULD NOT contain the Extension field
   1. CertificateIssuer (OID: 2.5.29.29).

The InvalidityDate and CertificateIssuer extensions SHALL have values compliant with RFC 5280.

The CRLReason extension SHALL have its critical field set to FALSE.

Its extValue field SHALL indicate the most appropriate reason value for revocation of the certificate when NOT submitted by subscribers.

Excluding the exception below, the extValue field values SHALL be limited to the following reason codes:

• keyCompromise (1): It is known or suspected that the private key of the certificate was compromised.
• cACompromise (2): It is known or suspected that the private key of the certificate’s issuing certificate was compromised.
• affiliationChanged (3): One or more attribute values in a subject’s Distinguished Name or Alternative Name Extension fields no longer hold true due to e.g. change of affiliation or change of surname. There is no cause to suspect that the private key has been compromised.
• superseded (4): A new certificate was issued to replace this one and the reason does not fall under any of the other reasons. Examples where this revocation reason is used can be (but are not limited to) a failed smart card, a forgotten password for a user token, or replacing a certificate due to mis-issuance (compliance irregularities). There is no cause to suspect that the private key has been compromised.
• cessationOfOperation (5): The certificate owner stopped operation or the certificate is no longer needed for the purpose for which it was issued. There is no cause to suspect that the private key has been compromised.
• privilegeWithdrawn (9): Indicates that there has been a subscriber-side infraction that has not resulted in keyCompromise, such as the Certificate Subscriber provided misleading information in their Certificate Request or has not upheld their material obligations under the Subscriber Agreement or Terms of Use.
• cACompromise (10): It is known or suspected that an attribute authority (any external source used to validate one or more attribute values in a subject’s Distinguished Name or Alternative Name Extension fields) had been compromised during the time of validation. There is no cause to suspect that the private key of the subscriber certificate has been compromised.

TSPs SHALL adhere to the definitions supplied above for revocation reasons. If subscribers submit reason codes the TSP SHALL clearly communicate their intended purposes and urge subscribers to adhere to them.

Comment

The following revocation reasons have been defined by PKI standards but for varying reasons are not in use by PKIoverheid. They are supplied for reference purposes only.

• unspecified (0): For metrics purposes this reason code adds no value and therefore is not permitted. The CA/Browser Forum Baseline Requirements also prohibits using this reason code.
• certificateHold (6): This reason code is prohibited for TLS certificates in both the CA/B Forum Baseline Requirements and the Mozilla Root Store Policy (see also this discussion), as well as in the strict profiles stipulated in the S/MIME Baseline Requirements. PKIoverheid has adopted these stipulations for all of its certificate types. In the past usage within PKIoverheid was limited to publicly-trusted TLS certificates issued as pre-certificates to a Certificate Transparency (CT) Log, but afterwards not issued as actual certificates.
• (7): Reason code 7 is not used within both RFC 5280 and ITU-T X.509.
• weakAlgorithmOrKey (11): This reason code indicates that the public-key certificate was revoked due to a weak cryptographic algorithm and/or key (e.g. due to short key length or unsafe key generation). While this may be a useful reason code, it is only specified in ITU-T X.509 and not in RFC 5280 which is leading within PKIo. When a certificate is revoked due to a weak cryptographic algorithm and/or key the reason code superseded (4) should be used instead as it constitutes a compliance irregularity.

7.2.3 Certificate Revocation List content; Application of RFC 5280

PKIo Certificate Revocation Lists (CRL) SHALL NOT contain fields and extensions other than those described or referenced under this section.

7.2.3.1 tbsCertList:version

See Section 7.2.1.

7.2.3.2 tbsCertList:signature

The tbsCertList:signature in PKIo Certificate Revocation Lists (CRL) SHALL comply with the relevant stipulations in Section 7.1.3.2.

7.2.3.3 tbsCertList:issuer

The encoded content of the tbsCertList:issuer field SHALL be byte-for-byte identical with the encoded form of the tbsCertificate:subject field of the TSP certificate signing the CRL.

7.2.3.4 tbsCertList:thisUpdate

The tbsCertList:thisUpdate field SHALL be present in PKIo Certificate Revocation Lists (CRL).

The tbsCertList:thisUpdate field SHALL include the issuance date of the CRL in UTCTime format in accordance with the applicable policy set out in the CPS.

7.2.3.5 tbsCertList:nextUpdate

The tbsCertList:nextUpdate field SHALL be present in PKIo Certificate Revocation Lists (CRL).

The tbsCertList:nextUpdate field value SHALL NOT be more than 48 hours later than the time set in the tbsCertList:thisUpdate field. This value SHALL be in UTCTime format.

7.2.3.6 tbsCertList:revokedCertificates

The tbsCertList:revokedCertificates field SHALL be present in PKIo Certificate Revocation Lists (CRL) when one or more certificates have been revoked in scope of that CRL.

The tbsCertList:revokedCertificates field in PKIo Certificate Revocation Lists SHALL contain the fields:

1. userCertificate with an RFC 5280 compliant value, and
2. revocationDate with an RFC 5280 compliant value, and
3. crlEntryExtensions with an Extensions field as value. The contents of this Extensions field is described in Section 7.2.2.2.

7.2.3.7 tbsCertList:crlExtensions

See Section 7.2.2.1.

7.3 OCSP Response profile

All OCSP responses

1. SHALL be compliant with the RFC 6960 OCSP response profile, and
2. SHALL NOT contain fields and extensions other than those described or referenced under this section.

7.3.1 Version number(s)

OCSP responses with a responseBytes:responseType identifier of BasicOCSPResponse SHALL have the tbsResponseData:ResponseData:version set to version 1 (integer 0), contained in the responseBytes:response field.

7.3.2 OCSP extensions

OCSP responses with a responseBytes:responseType identifier of BasicOCSPResponse MAY contain

1. the tbsResponseData:ResponseData:responses:singleResponse:singleExtensions:Extensions field, and/or
2. the tbsResponseData:ResponseData:responseExtensions:Extensions field,

in their corresponding responseBytes:response field.

Both Extensions fields MAY contain the extension

1. Nonce (OID: 1.3.6.1.5.5.7.48.1.2), and/or
2. Crl (OID: 1.3.6.1.5.5.7.48.1.3), and/or
3. Response (OID: 1.3.6.1.5.5.7.48.1.4), and/or
4. NoCheck (OID: 1.3.6.1.5.5.7.48.1.5), and/or
5. ServiceLocator (OID: 1.3.6.1.5.5.7.48.1.7), and/or
6. PreferredSignatureAlgorithms (OID: 1.3.6.1.5.5.7.48.1.8), and/or
7. ExtendedRevoke (OID: 1.3.6.1.5.5.7.48.1.9), and/or
8. any of the CRL Entry Extensions from Section 7.2.2.2, and

SHOULD contain the extension

1. ArchiveCutoff (OID: 1.3.6.1.5.5.7.48.1.6).

The singleExtensions extensions of an OCSP response SHALL NOT contain the reasonCode (OID: 2.5.29.21) CRL entry extension.

Comment 1

Usage of the Nonce extension offers protection against Replay Attacks which should make it a worthwhile extension to support. However, using this extension does make it easier to perform a Denial of Service (DoS) attack on an OCSP responder since every response has to be computed separately.

Comment 2

In general, support in client software for OCSP extensions is low.

Comment 3

The rationale for ArchiveCutOff extension usage can be found in ETSI standard 319 411-2 requirement CSS-6.3.10-10 stating “[CONDITIONAL]: If OCSP is provided, the OCSP responder should use the ArchiveCutOff extension as specified in IETF RFC 6960 [i.9], with the archiveCutOff date set to the CA’s certificate notBefore time and date value”.

7.3.3 OCSP Response content; Application of RFC 6960

Each OCSP response SHALL contain both the responseStatus and responseBytes fields, except when the responseStatus field contains an error condition in which case the responseBytes field SHALL NOT be present. Other fields SHALL NOT be present.

Permitted values of both these fields SHALL comply with RFC 6960 and any additional requirements stipulated in the sub-sections of this Section.

7.3.3.1 responseStatus

No stipulation.

7.3.3.2 responseBytes

The responseBytes:responseType field SHALL contain the id-pkix-ocsp-basic (OID: 1.3.6.1.5.5.7.48.1.1) identifier.

The responseBytes:response field SHALL contain a BasicOCSPResponse as value.

The BasicOCSPResponse SHALL contain all applicable fields and values described in the sub-sections of this Section, and SHALL NOT contain any other field.

7.3.3.2.1 responseBytes:response:BasicOCSPResponse:tbsResponseData

The responseBytes:response:BasicOCSPResponse:tbsResponseData field SHALL contain ResponseData containing all applicable sub-fields and values described in the sub-sections of this Section, and SHALL NOT contain any other sub-field.

7.3.3.2.1.1 version

See Section 7.3.1.

7.3.3.2.1.2 responderID

No stipulation.

7.3.3.2.1.3 producedAt

No stipulation.

7.3.3.2.1.4 responses

The responseBytes:response:BasicOCSPResponse:tbsResponseData:responses field MAY contain one or more SingleResponse fields.

Each SingleResponse field

1. SHALL contain a
   1. certID field, and
   2. certStatus field, and
   3. thisUpdate field, and
2. MAY contain a
   1. nextUpdate field, and/or
   2. singleExtensions field.

Contents of each of the SingleResponse sub-field SHALL be compliant with RFC 6960.

When the certStatus field contains the revoked status field, it MAY contain the RevokedInfo:revocationReason:CRLReason field. This CRLReason field SHALL contain a value permitted for CRLs, as specified in Section 7.2.2.2.

The singleExtensions field SHALL contain one Extensions field from the possible Extension fields described in Section 7.3.2 “OCSP Extensions”.

7.3.3.2.1.5 responseExtensions

Basic OCSP Responses MAY contain the tbsResponseData:responseExtensions field.

The tbsResponseData:responseExtensions field SHALL contain one Extensions field. This Extensions field SHALL contain one or more Extension fields which are described in Section 7.3.2.

7.3.3.2.2 responseBytes:response:BasicOCSPResponse:signatureAlgorithm

See Section 7.1.3.2.

7.3.3.2.3 responseBytes:response:BasicOCSPResponse:signature

No stipulation.

7.3.3.2.4 responseBytes:response:BasicOCSPResponse:certs

No stipulation.

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

8.1 Frequency or circumstances of assessment

The TSP SHALL have a full audit performed on their PKIoverheid systems annually against the requirements listed in section 8.4.

The audit SHALL include the scope and audit criteria from the Overview of Applicability (OoA) approved by the PA PKIoverheid for that audit.

At the latest one (1) full month before the commencement of the audit the TSP SHALL submit an OoA to the PA PKIoverheid

1. which meets the format requirement set by the PA PKIoverheid, and
2. which outlines the audit criteria, services, and certificates in scope for the audit.

Comment 1

The PA PKIoverheid maintains a lead-time of 15 working days for the review and approval process of an OoA

Comment 2

If one of these conditions is not met the PA reserves the right to reject the audit report and request a re-audit.

Comment 3

An up-to-date version of the OoA can be requested from the PA PKIoverheid.

8.2 Identity/qualifications of assessor

The TSP’s audit SHALL be performed by a Qualified Auditor. A Qualified Auditor is a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively SHALL possess the following qualifications and skills:

1. independence from the subject of the audit, and
2. the ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme, and
3. employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third party attestation function, and
4. accredited in accordance with the ETSI EN 319 403 scheme by an accreditation body within the meaning of Article 4 of Regulation (EC) No 765/2008, and bound by law, government regulation, or professional code of ethics.

Comment

Criteria for an Eligible Audit Scheme, if present, are described in Section 8.4 of this PoR.

8.3 Assessors relationship to assessed entity

No stipulation.

8.4 Topics covered by assessment

8.4.1 Requirements covered by assessment

The applicable audit requirements SHALL at least consist of

1. the PKIoverheid Programme of Requirements, and
2. the CA/Browser Forum Network and Certificate System Security Requirements, and
3. for CAs issuing or intending to issue eIDAS Qualified certificates
   1. ETSI EN 319 411-2 with policy
      1. QCP-n-qscd (ETSI OID 0.4.0.194112.1.2) for Qualified certificates issued to natural persons, and
      2. QCP-l-qscd (ETSI OID 0.4.0.194112.1.3) for Qualified certificates issued to Legal Entities, and
   2. REGULATION (EU) No 910/2014, and
4. ETSI EN 319 411-1 with policy
   1. NCP+ when the CA contains the value ncpplus (OID 0.4.0.2042.1.2) as a policyIdentifier value in its extensions:certificatePolicies:extValue field, and
   2. NCP when the CA does NOT contain the value ncpplus (OID 0.4.0.2042.1.2) as a policyIdentifier value in its extensions:certificatePolicies:extValue field, and
5. ETSI TS 119 411-6 for CAs which contain the emailProtection EKU,

all in the latest published version which has gone into effect, available at the commencement of the audit.

Comment

When new versions of audit requirements (or referenced documents therein) are published, some standards bodies allow for grace periods for using a former version. If a TSP wishes to make use of such a grace period this can be requested from the PA PKIoverheid through the regular dispensation process. In general the PA PKIoverheid will approve this dispensation. However, when the latest version of audit criteria fixes issues deemed highly important for PKIoverheid, the PA may decide otherwise. Additionally, when the audit concerns an Issuing Certificate in a publicly-trusted root hierarchy, Browser Trusted Root Store Policies also apply which may include a specific version of these schemes to be audited against (currently only Mozilla specifies these version numbers). In those cases dispensations are not possible.

8.4.2 Changes in requirements covered by assessment

The TSP SHALL submit a statement on compliance with future changes in audit criteria when requested by the PA PKIoverheid before the effective date of the change in question. This statement SHALL use a template provided by the PA PKIoverheid and SHALL be signed by a Legal Representative or Delegated Legal Representative of the TSP.

1. ETSI EN 319 411-1 with policies NCP (ETSI CP OID 0.4.0.2042.1.1) and OVCP (ETSI CP OID 0.4.0.2042.1.7), and
2. CA/Browser Forum Network and Certificate System Security Requirements.

Comment

If a TSP fails to comply the PA reserves the right to demand suspension of certificate issuance until the TSP can comply with the stated change.

8.4.3 Parties covered by assessment

If the TSP uses an external Registration Authority (RA), Reseller, or any other third party with access to its information systems, user accounts, and/or which takes part in processes enabling issuance or approval of certificates, any and all of these parties SHALL be in scope of the TSP’s PKIoverheid assessments.

Therefore the TSP SHALL contractually bind these parties to comply with the PKIoverheid Programme of Requirements.

Comment

This requirement expands on ETSI EN 319 401 OVR-6.9.1-01 referencing ETSI EN 319 401 requirement REQ-7.1.1-08. When the TSP makes use of other parties, including trust service component providers, to provide parts of its service through subcontracting, outsourcing or other third party arrangements, it shall maintain overall responsibility for meeting the requirements defined in the trust service policy.

8.4.4 Assessment reports

The TSP SHALL make sure the audit attestation includes all the requirements its certificates are audited against.

Comment

Requirements as referred to in this Section should be interpreted as standards or baselines as stipulated in Section 8.4.1 and not as individual requirements described in these standards.

8.5 Actions taken as a result of deficiency

No stipulation.

8.6 Communication of results

The TSP SHALL be responsible for communicating with the PA PKIoverheid any and all

• audit attestations,
• audit findings, and
• updates on the resolution of findings,

including from any and all external Registration Authorities (RA), Resellers, or other third parties in scope of the TSP’s PKIoverheid assessments, within 3 working days of the documents being marked as final.

Comment

The time frame mentioned above is in line with the reporting procedure employed by the Dutch Authority for Digital Infrastructure (RDI).

9. OTHER BUSINESS AND LEGAL MATTERS

9.1 Fees

9.1.1 Certificate issuance or renewal fees

No stipulation.

9.1.2 Certificate access fees

No stipulation.

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

No stipulation.

Comment

This topic is described in ETSI EN 319 401 requirement REQ-7.1.1-04.

9.2.1 Insurance coverage

No stipulation.

9.2.2 Other assets

No stipulation.

9.2.3 Insurance or warranty coverage for end-entities

No stipulation.

9.3 Confidentiality of business information

9.3.1 Scope of confidential information

No stipulation.

9.3.2 Information not within the scope of confidential information

No stipulation.

9.3.3 Responsibility to protect confidential information

No stipulation.

9.4 Privacy of personal information

9.4.1 Privacy plan

No stipulation.

9.4.2 Information treated as private

No stipulation.

9.4.3 Information not deemed private

No stipulation.

9.4.4 Responsibility to protect private information

No stipulation.

9.4.5 Notice and consent to use private information

No stipulation.

9.4.6 Disclosure pursuant to judicial or administrative process

No stipulation.

9.4.7 Other information disclosure circumstances

No stipulation.

9.5 Intellectual property rights

The TSP SHALL indemnify the subscriber in respect of claims by third parties due to violations of intellectual property rights by the TSP.

9.6 Representations and warranties

9.6.1 CA representations and warranties

9.6.1.1 CA Representation for third parties

In the agreement between the TSP and the subscriber, the TSP SHALL include a clause (as specified in Article 253 of the Dutch Civil Code, Book 6) in which it champions the interests of a third party relying on the certificate. This clause SHALL address liability of the TSP in accordance with EU Regulation No 910/2014 (eIDAS) Article 13 and applies to all certificates issued by the TSP.

9.6.1.2 S/MIME warranties

TSP issuing S/MIME capable certificates SHALL indicate compliance with the SBRG by inserting the following phrase into their CPS in Section 1.1: “[Name of TSP] conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates published at https://www.cabforum.org. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.”.

Comment

This requirement further specifies stipulations in Section 2.2 of the SBRG.

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

No stipulation.

9.8 Limitations of liability

The TSP SHALL include in the subscriber agreement that the TSP and the PA PKIoverheid cannot be held liable for damages resulting from the improper use of the certificate, as outlined in Section 1.4.

To prohibit additional limitations of liability, the TSP

• SHALL NOT place restrictions on the use of certificates within the scope of certificates as mentioned in Section 1.4, except for
  • certificates issued under the G3 Autonomous Devices domain certificate, and
  • non-repudiation certificates, provided these restrictions including warranties are clearly communicated to third parties, and
• SHALL NOT place restrictions on the value of the transactions for which certificates can be used.

Comment

The clause related to non-repudiation certificates is based on Dutch Civil Code article 196b, paragraph 3.

9.9 Indemnities

No stipulation.

9.10 Term and termination

9.10.1 Term

No stipulation.

9.10.2 Termination

No stipulation.

9.10.3 Effect of termination and survival

No stipulation.

9.11 Individual notices and communications with participants

No stipulation.

9.12 Amendments

A TSP submitting a Request for Change (RFC) for this document SHALL adhere to the change procedure as outlined in the PKIoverheid Certification Practice Statement (CPS).

9.13 Dispute resolution provisions

The complaints handling process and dispute resolution procedures applied by the TSP SHALL NOT prevent proceedings being instituted with the ordinary court.

9.14 Governing law

Dutch law SHALL apply to all agreements the TSP enters into under this Programme of Requirements (PoR), unless specified otherwise.

9.15 Compliance with applicable law

No stipulation.

9.16 Miscellaneous provisions

9.16.1 Entire agreement

No stipulation.

9.16.2 Assignment

No stipulation.

9.16.3 Severability

No stipulation.

9.16.4 Enforcement (attorneys’ fees and waiver of rights)

No stipulation.

9.16.5 Force Majeure

No stipulation.

9.17 Other provisions

9.17.1 Reporting on issued certificates

The TSP SHALL provide the PA PKIoverheid with data twice a year on the total number of issued certificates over the preceding period and total amount of currently valid certificates using a template provided by the PA.

9.17.2 CA Operational Changes

If an event occurs or may occur as described in Chapter 8 of the Mozilla Root Store Policy (MRSP), a TSP with technically unconstrained issuing certificates as described in section 5.3.1 of the MRSP, SHALL

• inform the PA PKIoverheid without delay,
• not take (irreversible) actions without the approval of the PA PKIoverheid, and
• take all possible actions to (permanently) meet the requirements in Chapter 8 of the MRSP.

Comment

The Mozilla Root Store Policy (MRSP) can be found here https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy.