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. 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
• DEPRECATED: G3 Server certificates (previously 3e)
• DEPRECATED: EV Server certificates (previously 3f)
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Private Private Person certificates (previously 3i)
• Server 2020 certificates (previously 3j)

The PKIoverheid Requirements document structure complies with RFC 3647 and each individual requirement has a unique and persistent number.

The table below shows the structure within which all PKIoverheid requirements are specified individually.

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.
• Attribuut 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 requirementd 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 equirements 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 attribte 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 equirements 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).
• Minnor 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 editiorial 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 inder domains G3 Organization Person, G3 Organization Services, G3 Citizens, G3 Autonoumous 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 certificatesunder 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).
• Probihition 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 (effectrive 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:organizationIdentifer.
• 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 ommission 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 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 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-assesment (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 contrained 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 wich 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 attribte 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 warrenty about S/MIME compliance.
• Create 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 “sponsor-validated certificates” to Section 1.6.2.
• Added SBRG abbreviation to Section 1.6.3.
• Change applicability list in all requirements to reflect renamed and new certificate types.
• Expand requirement 2.2-pkio166 to include email validation.
• Expand applicability of requirements 2.2-pkio166 and 2.2-pkio191 to include new 2023 and S/MIME profiles.
• Expand requirement 2.2-pkio166 to include email validation.
• Expand applicability of requirements 2.2-pkio166 and 2.2-pkio191 to include new 2023 and S/MIME profiles.
• Expand 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.
• Expand 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.
• Make requirement 5.4.1-pkio80 a basic requirement.
• Updates on audit log retention in requirement 5.4.3-pkio81.
• Expand applicability of requirements 5.5.1-pkio82 and 5.7.4-pkio86 to include new 2023 and S/MIME profiles.
• Expand 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.
• Replace NCSC reference no longer maintained with an OWASP alternative and fix a broken link in Section 6.7.1.
• Expand 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.
• Make emailProtection EKU no longer mandatory but optional in requirement 7.1-pkio149.
• Consolidate requirements 7.1-pkio50 and 7.1-pkio51 into requirement 7.1-pkio149.
• Retrofit id-kp-documentSigning EKU in requirement 7.1-pkio151.
• Reference requirement 7.1-pkio149 in the extendedKeyUsage explanation field of all the different certificate profiles.
• Make requirement 7.1-pkio149 a basic requirement.
• Updated text in requirements 7.1-pkio163 and 7.1-pkio165 with PoR 5.0 retrofit.
• Expand applicability of requirements 8.4-pkio194, 8.4-pkio195, 8.4-pkio196, and 8.4-pkio200, to include new 2023 and S/MIME profiles.
• Expand requirements 8.4-pkio194 and 8.4-pkio195 with SRBG requirements.
• Rewrite requirement 8.4-pkio197 for publicly trusted S/MIME certificates.
• Expand 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.
• Standardize 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.
• Remove section on commonName naming convention from all Certificate Profiles for natural persons.
• Add SBRG policy OIDs to G3 Legacy profiles.

Removals

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

Editorial

• Fix upper and lower case usage in various ASN.1 field names.
• Add missing reference “section 5.1.2” to the text which describes ECDSA in requirement 6.1.1-pkio89.
• Remove both instances of line “(latest published version applies)” from requirement 8.4-pkio197.
• Retrofit missing “applicable to” field to requirements 9.6.1-pkio127, 9.6.1-pkio131, 9.6.1-pkio132, and 9.6.1-pkio142.
• Insert 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.

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 refered 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 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 authorizated 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). Before issuance of the first certificate the subscriber has to 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 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.
• G3 Server certificates (previously 3e): DEPRECATED !
• EV Server certificates (previously 3f): DEPRECATED !
• 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 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
• Server 2020 certificates (previously 3j):
  • [OID 2.16.528.1.1003.1.2.5.9]: 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. Certificates issued with this OID are in accordance with the then current version of the Baseline Requirements. In the case of discrepancies between this PoR and the Baseline Requirements, the latter takes precedence over this document.
• 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 Server 2020 and 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 key words “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

Applicant

A natural person or legal personality who submits an application to a Registration Authority for the issue of a certificate.

Subscriber

A natural person or legal personality who is party to an agreement with a provider of public telecommunications services for the supply of such services.

Within the scope of the PKI for the government:

A subscriber enters into an agreement with a TSP on behalf of one or more certificate holders. How the delivery of certificates takes place is organized between the subscriber and the TSP. In the Citizen domain, the subscriber and certificate holder are always the same party.

Accreditation

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

Advanced electronic signature

See “Advanced electronic signature”.

Advanced Encryption Standard – AES

The new standard for encrypting data, determined by NIST and valid for the United States. The AES serves as successor to the much-used DES algorithm and, to a lesser extent, the SHA-1 algorithm. The AES utilises the Rijndael algorithm, developed in Belgium.

Independence and Vulnerability Analysis - I&V analysis

The analysis is implemented with the goal of determining the level of security required to guarantee trusthworthy communication within the infrastructure of the PKI for the government.

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.

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

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.

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.

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

Authentication

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

Authenticity certificate

A certificate that, depending on the specific application, is used for authentication or electronic identification.

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.

Authorization

Granting authority to perform actions (such as viewing, modifying or processing) on information or devices.

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.

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.

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.

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;

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 thus 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”.

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.

CEN Workshop Agreement - CWA

A document from the European Committee for Standardization (CEN) containing advice and proposals for European standardization. In comparison with realising an ETSE standard, the realization of advice from the CWA is much faster. On the other hand an ETSE standard is considered more as an official starting point.

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

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

In the case of personal certificates the certificate holder will be a natural person, in the case of service certificates the certificate holder will be a function or a machine/server. In the Citizen domain, certificate holder and subscriber are always the same party.

Certificate Profile

A description of the content of a certificate. Each kind of certificate (signature, confidentiality, etc) in each domain has its own content and therefore its own description. This includes, for example agreements regarding naming, etc.

Certificate Generation Service

A service that creates and signs certificates, based on identity and other characteristics verified by the Registration Authority.

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 Revocation List – CRL

A publicly accessible and consultable list (database) of revoked certificates, made available, signed and falling under the responsibility of the issuing TSP.

Certification

A broad (both technical as well as non-technical) evaluation of the security properties of an information system or, as in the framework of the PKI for the government, a management 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 (ETSI EN 319 411-2). The instruction for certification are recorded in a scheme: Scheme for Certification of Certification Authorities against ETSI EN 319 411-2.

Certification Services

Issuing, maintaining and revoking certificates by trust service providers as well as other services that are connected with using electronic signatures, identity and confidentiality.

Certification Service Provider

See “Trust Service Provider”.

Certification Authority – CA

An organizational network that is a part of a Trust Service Provider or that operates under responsibility of the Trust Service Provider and that is trusted by one or more end users to make (generate) issue and revoke Certificates. A CA can also create keys for end users (optional). See also the diagram under “Hierarchical model”.

Certification Practice Statement – CPS

A document that describes the procedures and measures followed by a TSP regarding all aspects of the service. In this, the CPS describes the way in which the TSP satisfies the requirements described in the applicable CP.

Trust Service Provider - TSP (NL: Vertrouwensdienstverlener)

A natural or legal person that issues certificates or other services provided in connection with electronic signatures. [Electronic Signatures Act]

In the framework of the PKI for the government the TSP can also provide services in connection with identity and confidentiality.

A TSP’s function is to issue and manage certificates and key information, including the carriers provided for this (for example smartcards). The TSP also has final responsibility for delivering the certification services. It is not important here if the TSP implements the actual activities itself or contracts this out to others. It is for example not unthinkable that a TSP contracts out the CA function and/or the RA function. See also the diagram under “Hierarchical model”.

Trust Service Provider-Certificate Policy – TSP CP

A Certificate Policy concerning the certificate from the TSP.

Client

See “End User”.

Client Certificate

See “End User Certificate”.

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

A name of the certificate holder comprising, in the case of a personal certificate: surname, first name[s] and any initials. The certificate issuer can also be given a commonName. If so, this will mostly comprise a company name supplemented with the domain applicable to the PKI for the government.

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.

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

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.

TSP certificate

A certificate of a TSP. With the TSP certificate a TSP describes the CAs operating under it. Within the PKI for the government a TSP certificate is issued by the Domain CA under responsibility of the PA (Policy Authority). See also the diagram under “Hierarchical model”.

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

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. The new Advanced Encryption Standard (AES) is a successor to this.

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.

Digital Signature

See “Advanced electronic signature”.

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.

Dissemination Service - DS

A service that distributes the certificates among subscribers and, with consent from the subscribers, to relying parties. The service also distributes the Certificate Policies and Certification Practice Statements among the certificate holders, subscribers and relying parties.

Distinguished Name - DN

The unique label of the name of a certificate holder, comprising minimally of: country, name, serial number and (in the case of certificates in the Government/Companies and Organization domain) organization name.

Domain certificate

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

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

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.

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]

Electronic signature (NL:Elektronische handtekening)

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.

Within the scope of the PKI for the government:

The electronic signature is used to ensure that electronic correspondence and transactions can compete with the time-honoured “signature on paper” on two important points. By placing an electronic signature it is established that someone who says they have signed a document has also actually done this. A person who places an electronic signature, indicates that he/she subscribes to the content of the document. Furthermore, the reader can also check afterwards whether the signature is from the correct person and whether the document has remained unchanged.

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.

Encryption

A process with which data become encrypted using a mathematical algorithm and a cryptographic key so that these become unreadable for unauthorized persons.

The trustworthiness of the encryption depends on the algorithm, the implementation of this, the length of the cryptographic key and the use discipline.

For symmetric encryption the same secret key is used for encryption and decryption.

For asymmetrical encryption use is made of a key pair. One key, the private key, is only known by the end user of this key and needs to be kept strictly secret. The other, the public key, is distributed among the communication partners. Text encrypted with the private key, can only be decrypted with the accompanying public key and vice versa.

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.

Entry

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

eNIK

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

Recognized profession

In the framework of the PKI for the government a practitioner of a recognized profession is only considered a natural person who is in possession of:

• either a valid proof of registration in a (professional) register recognized by the relevant professional group, to which disciplinary rules stipulated by law apply;
• or valid proof (e.g. a permit) that the legal requirements in relation to practising a profession, are fulfilled.

European Electronic Signature Standardization Initiative - EESSI

A workshop at European level tasked with making concrete the standardization agreements from the European Directive 1999/93/EC for electronic signatures.

European Telecommunications Standards Institute – ETSI

An organization responsible for determining standards and norms in the area of telecommunications that are valid for the whole of Europe.

European Directive

In the framework of PKI, this alludes to document 1999/93/EC from the European Parliament and Council dated 13 December 1999 concerning a common framework for electronic signatures (Publicatieblad no. L013 of 19/01/2000, p.12-20).

Evaluation Assurance Level - EAL

A package comprising confidentiality components from ISO/EIC 15408 Part 3 that represent a point on the reliability scale as defined in the Common Criteria.

Extended Normalized Certificate Policy – NCP+

A Certificate Policy for non-qualified certificates that gives the same quality level as qualified certificates (in the QCP), but outside the working of the European Directive. This is used in situations in which the use of an SUD is deemed necessary.

Extended Validation SSL certificaten

EV SSL certificates are issued according to the Extended Validation directive in which strict demands are set on verifying the organization that applies for the SSL certificate and the domain for which the certificate is requested. One of the most important properties of an Extended Validation SSL certificate is that this makes the address bar of, for example Internet Explorer (version 7 and further) turn green.

Exclusivity

See “Confidentiality”.

FINREAD

An open standard for smartcard readers that makes secure authentication possible on the internet. This standard is a result of a European initiative from a number of financial institutions and focuses on being able to implement electronic banking transactions. Within FINREAD (in full: FINancial READer) specifications cryptographic processes are handled by the card reader and not by the smartcard.

Manufacturer

In the framework of the PKI for the government a Manufacturer is an organization recognised in the Netherlands that conforms demonstrably to the Framework of Standards for producing and distributing a specific type of Autonomous Device in the Netherlands and is then also authorized by the party responsible for establishing the framework.

Federal Information Processing Standard – FIPS

An official standard for the United States and issued by NIST. In the framework of PKI, FIPS 140 (“Security Requirements for Cryptographic Modules”) and FIPS 186-2 (“Digital Signature Standard”) are of main importance.

Fully Qualified Domain Name (FQDN)

A Fully-Qualified Domain Name (FQDN) according to the PKloverheid definition, is a full name registered in the Internet Domain Name System (DNS) with which a server on the internet can be identified and addressed uniquely. With this definition a FQDN contains all DNS nodes, up to the name of the Top Level Domain (TLD) concerned, and a FQDN is, in the Internet DNS, registered under a DNS Resource Record (RR) of the type ’IN A" and/or “IN AAAA” and or “IN CNAME”.

Examples of FQDNs are

• www.logius.nl
• webmail.logius.nl
• local.logius.nl
• server1.local.logius.nl
• logius.nl (if registered under a DNS RR of the type “IN A” and/or “IN AAAA” and/or “IN CNAME”)

Examples of non-FQDNs (and thus not permitted within PKloverheid) are:

• www
• logius.nl (if NOT registered under a DNS RR of the type “IN A” and/or “IN AAAA” and/or “IN CNAME”)
• server1.webmail
• server1.local
• server1.

Advanced electronic signature (NL: Geavanceerde elektronische handtekening)

An electronic signature that fulfils the following requirements:

1. This is linked uniquely to the signatory;
2. This enables the signatory to be identified;
3. This is established using devices that the signatory can keep under its exclusive control;
4. This is linked in such a way to the electronic file to which it relates that every subsequent change of data can be traced;

[European Directive]

In – particularly dated – literature the term “Digital signature” is sometimes used. In comparison to a qualified electronic signature, an advanced electronic signature is not a legally valid signature in all circumstances.

User

See “End User”.

User Certificate

See “End User Certificate”.

Data for producing electronic signatures

See “Signature creation data”.

Data for verifying an electronic signature

See “Signature verification data”.

Secret key

A cryptographic key that is used for a symmetrical cryptographic algorithm. In asymmetric cryptography - as used for such things as the PKI for the government - secret keys are not used.

Qualified certificate (NL:Gekwalificeerd certificaat)

A certificate that satisfies the requirements set in accordance with article 18.15, second paragraph of the Telecommunications Act, and is issued by a certification provider that satisfies the requirements set in accordance with article 18.15, first paragraph of the Telecommunications Act. [Electronic Signatures Act]

In the framework of the Electronic Signatures Act only the signature certificate is considered. In the framework of the PKI for the government however, two other types of certificates are processed. Only the signature certificate is considered here as a qualified certificate. The confidentiality certificate and the authenticity certificate are not qualified certificates but do have the same trust level within the PKI for the government.

Qualified electronic signature (NL:Gekwalificeerde elektronische handtekening)

An electronic signature that fulfils the following requirements:

1. This is linked uniquely to the signatory;
2. This enables the signatory to be identified;
3. This is established using devices that the signatory can keep under its exclusive control;
4. This is linked in such a way to the electronic file to which it relates that every subsequent change of data can be traced;
5. This is based on a qualified certificate as intended in article 1.1, part ss Telecommunications Act; and
6. It is generated by a secure tool for producing electronic signatures as intended in article 1.1, part vv Telecommunications Act.

[Electronic Signatures Act]

Explanation:

The Act intends to make the qualified electronic signature legally valid by making its operation equal to that of the handwritten signature.

It is stated literally in the Act that if an electronic signature satisfies a) to f) the used “method is assumed to be sufficiently trusthworthy.” However, no name is given to these types of signatures. In the ETSI standard EN 310 411-2 the name “Qualified electronic signature” is given to the electronic signature that satisfies that from a) to f). The above-chosen name is thus the most obvious and thus fills the omission in the Act.

Glue

Software that forms the bridge between the applicative functions, as run at clients and on servers, and the cryptographic functions, as implemented through smartcards and card readers.

Generic TopLevelDomein (gTLD)

The gTLD is a generic top level domain, a domain name extension that does not belong to a certain country and can be registered in principle by everyone anywhere in the world. Some examples of gTLD’s are .com, .edu, .gov, .mil and .org.

Signature certificate

A certificate that is used in placing an electronic signature.

Hardware Security Module - HSM

The peripheral device used on the server side to speed up cryptographic processes. The production of keys should particularly be considered here.

Hash function

A function that transforms a message of random length into a series of fixed length and satisfies the following conditions:

• It is practically unfeasible for a given output to find an input that has this (“one-way”) output as a result;
• It is practically unfeasible for a given input to find a second input that has this same (“weak collision-free”) output as a result;
• It is practically unfeasible to find two random messages that have the same (“strong collision-free”) output as result.

Hash value

The result, (output) of a hash function. The hash value is also called “message digest”.

Hierarchical model

The PKI for the government assumes a hierarchical model. This means that trust in a chain is forwarded. An end user can trust all Certification Authorities that fall within the same CA stem.

Identification

Establishing the identity of a person (or business).

Identity and Authentication Certificate

See “Authentication certificate”.

Identity Certificate

See “Authenticity certificate”.

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.

Indirect physical manifestation

A concept that is used when a person’s identity control is not effected using the personal presence of that person, but is instead effected using tools that give the same certainty as can be obtained by personal presence.

Information Asset

A (stated) part of the information within an organization that is needed for the continuity of work processes (primary and secondary).

Integrity

The security that data are complete and unchanged, irrespective of whether this has occurred intentionally, unintentionally or has occurred in another way.

Internet Engineering Task Force – IETF

An international organization that strives to develop the internet architecture from the technical-scientific viewpoint.

Interoperability

The capacity to realize that different (automated) systems can work together technically.

Party responsible for establishing the framework

In the framework of the PKI for the government a Party responsible for Establishing the Framework is a government agency that:

• for a specific core task has a need for (measurement) data that originates from outside its immediate sphere of influence;
• to safeguard the integrity and authenticity of that (measurement) data, wishes to use specific devices that operate autonomously;
• to safeguard the trustworthiness of specimens of that type of device:
• draws up a framework of standards for the production, activation, operation, maintenance, collection and use and formulates this in legislation and regulations;
• based on that framework of standards, authorizes organizations to:
• produce and distribute devices of a particular type;
• link certificates to particular devices;
• replace certificates on particular devices;
• revoke certificates of particular types of devices.

Key-backup

Making a copy of a private key on issue. It is most often the intention to hand over this copy to an organization that can use this via a key-escrow.

Key-escrow

A storage method for (a copy of) a private key, in which this is lodged with a trusted third party (a so-called “Key Escrow Agency” - KEA). If necessary, authorized involved parties can obtain access to the key.

Key-recovery

The technology with which the key that is needed to decrypt an encrypted message can be converted by a third party.

Country code TopLevelDomein (ccTLD)

The ccTLD (country code Top Level Domain) is the domain name extension for a country or independent territory. A ccTLD is comprised of the 2-letter country code that is determined according to the ISO 3166-1 standard. E.g. .nl, .be and .de.

Suppliers statement

Statement from a supplier in which it asserts under its exclusive responsibility, that a product, process or service complies with a specified standard or other normative document.

Lightweight Certificate Policy – LCP

A Certificate Policy that is used for non-qualified certificates in situations in which a risk-analysis does not justify additional costs associated with the more stringent NCP demands (such as physical appearance during the application process).

Lightweight Directory Access Protocol - LDAP

An open protocol that enables applications to obtain information from directories, such as, for example e-mail addresses and keys.

Local Registration Authority - LRA

The organization entity or function to which the implementation of the task of Registration Authority is assigned, and that physically collects, verifies, registers and forwards the identification data of the applicant in order to issue the certificate.

Message Digest - MD

See “Hash value”.

MD5-algorithm

A much used algorithm for creating a cryptographic hash value for a message. The MD5-value of a certificate is unique to that certificate, and is often used to identify a certificate.

Multi-factor authentication

For this form of authentication, a minimum of two authentication techniques are applied simultaneously.

Non-Qualified certificate

A certificate that does not satisfy the requirements stated in accordance with article 18.15, second paragraph of the Telecommunications Act, and/or not is issued by a TSP that satisfies the requirements stated in accordance with article 18.15 first paragraph of the Telecommunications Act and/or not is applicable to serve for the advanced electronic signature.

Explanation: In the framework of the PKI for the government the Authenticity Certificate and the Confidentiality Certificate are formally non-qualified certificates but, in terms of content, do satisfy the same requirements and therefore have the same security level.

Non-repudiation (NL: Onloochenbaarheid, Onweerlegbaarheid)

The property of a message that demonstrates that certain events or actions have taken place, such as sending and receiving electronic documents.

Within the PKI for the government, non-repudiation (of the content of a message) is proven through means of a signature certificate.

Normalized Certificate Policy – NCP

A Certificate Policy for non-qualified certificates that gives the same quality level as applies to qualified certificates (in the QCP), but is outside the working of the European Directive 1999/93/EC and without a secure user device being required.

Notified body (NL: Aangemelde instantie)

A government body that is nominated by the government of an EU member state and has received notification of this by the EU, to implement tasks regarding conformity test procedures to which is referred in the EU’s “New Policy Directives” if a third party is required.

In the framework of electronic signatures such a government body is also referred to as a “designated body” and is as such appointed to determine whether a product satisfies the requirements for SSCDs on the basis of the European Directive 1999/93/EC.

Object Identifier - OID

A row of figures separated by points that designates an object in a unique and permanent way. Within the PKI for the government, OIDs are also awarded to all CPs and to all CAs.

Signatory (NL:Ondertekenaar)

The person who uses a signature creation device.

In the framework of the PKI for the government, signatory is understood to be the certificate holder of the signature certificate and the term ‘signatory’ itself is not used.

Online Certificate Status Protocol - OCSP

A method to monitor the validity of certificates online (and real-time). This method can be used as alternative for consulting the Certificate Revocation List.

Open Card Framework - OCF

By using Java and the Java Virtual Machine (VM) an open architecture will be realized on the basis of which compatible APIs can be delivered. It is therefore desirable that the smartcard reader supports the use of Java and Java VM.

Organization name

The name of the legal entity for which a subscriber is the contracting party. The organization name is demonstrated by means of an extract from the Trade Register or another official document from which states the name. In the case of an extract from the Trade Register, the trade name of a branch can be used as the organization name of that specific branch.

Organization-related certificates

There are two different kinds of organization-related certificates:

1. for persons;
2. for services.

At. 1

For organization-related certificates for persons the certificate holder is part of an organizational entity. The certificate holder has the authority to make a certain transaction on behalf of the organizational entity.

At. 2

For organization-related certificates for services, the certificate holder is:

• a device or a system (a non-natural person), operated by or on behalf of an organizational entity; or
• a function of an organizational entity.

Government

Within the context of PKIoverheid the following are considered to be government and government organizations:

• the whole central government, provinces, local councils, cooperative partnerships on the basis of the Joint Regulations Act and the water boards;
• implementing organizations and services such as inspections, financial services agencies and police services;
• judiciary;
• independent administrative bodies as stated in the ZBO register ^[1]

Government/Companies and Organization

Within the PKI for the government the Government/Companies and Organization domains comprise all organizations within the government and business world.

Personal Unblocking Key - PUK

The de-blocking code for cryptographic modules.

Personalization

A process in which blank cards are provided with personal data (photo and/or name&address data) and or personal key material.

It is probable that, in the framework of the PKI for the government, the personalization is implemented by two different providers, with one placing the key material in the presence of the end user and the other printing the card with the photo and the relevant personal data.

Personal certificates

In the case of personal certificates, the certificate holder will be a natural person. The certificate holder is either a part of an organizational entity for which a subscriber is the contracting party (organization-related certificate holder), or the practitioner of a recognized profession and in this capacity is also a subscriber and with this the contracting party (profession-related certificate holder), or a citizen and in this capacity is a subscriber and with this is the contracting party.

PKI for the government

The entire infrastructure that is maintained by the PA PKIoverheid.

PKI-enabled application

An application that is capable of using PKI functions such as placing an electronic signature.

Plug and Play - PnP

A standard for automatic configuration or installation of hardware tools.

Policy Authority – PA

An authority that sets the rules for that part of the hierarchy of a PKI that rests under its authority.

Policy Authority PKIoverheid – PA PKIoverheid

The Policy Authority (PA) for the hierarchy of the PKI for the government. The PA supports the Minister of Ministry of the Interior and Kingdom Relations in maintaining the PKI for the government. The PA’s service provision can be divided into the management of the top layer of the infrastructure, admitting TSPs to the infrastructure and supervising the reliability of the PKI for the government. See also the diagram under “Hierarchical model”.

Pre-personalization

A process in which white cards are provided with generic material (such as printing or generic keys) but not yet with personal data or personal key material.

Private IP address

An Internet Protocol address (IP address) is an identification number assigned to each device (e.g.. computer, printer) that participates in a computer network that uses the Internet Protocol (TCP/IP) for communication.

Private IP addresses are not routable on the internet and are reserved for private networks. The IP address series that is reserved within IPv4 for private use is (see RFC 1918):

• 0.0.0 – 10.255.255.255;
• 16.0.0 – 172.31.255.255;
• 168.0.0 – 192.168.255.255;

In addition the series from 169.254.0.0 -169.254.255.255 is reserved for Automatic Private IP Addressing (APIPA). These IP addresses may not be used on the Internet.

The IP address series that is reserved within IPv6 for private use is (see RFC 4193):

• fc00::/7

In addition the series from fe80::/10 is reserved for Automatic Private IP Addressing (APIPA). These IP addresses may not be used on the Internet.

Private key (NL:Private sleutel)

The key of an asymmetrical key pair that should only be known by the holder of this and kept strictly secret.

In the framework of the PKI for the government the private key is used by the user to identify him/herself electronically, place his/her electronic signature or to decrypt an encrypted message.

The term “privé sleutel” (private key) is also often used (including in the European Directive). In the Electronic Signatures Act, the word “private sleutel” is used. Both are intended as translation of the English term “private key”.

Process owner

A role in process management that defines goal measures, assures the consistent implementation of the process in their area of responsibility, requests resources to work on process improvements and assesses process changes and communicates process changes and improvements to process users.

Product for electronic signatures

See “Electronic-signature product”.

Protection Profile – PP

A collection of security requirements, independent of the implementation, for a category of TOEs that needs to satisfy specific customer requirements.

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

A compilation of architecture, technology, organization, procedures and rules, based on public key cryptography. The goal is to make reliable electronic communication and reliable electronic services possible.

Public key (NL:Publieke sleutel)

The key of an asymmetric Key pair that can be made public.

The public key is used to control the identity of the owner of the asymmetric key pair, to check the electronic signature of the owner of the asymmetric key pair and to verify information for a third party.

The term “openbare sleutel” (public key) is also often used (including in the European Directive). In the Electronic Signatures Act, the word “publieke sleutel” is used. Both are intended as translation of the English term “public key”.

Public IP address

Public IP addresses are unique across the world and are routable, visible and accessible from the internet.

Qualified Certificate Policy – QCP

A Certificate Policy that contains an implementation of the requirements that are described in article,18.15, first and second paragraph of the Telecommunications Act.

Trust Services regulation

Regulation of the Minister of Economic Affairs of 24 February 2017,

1. WJZ / 17028856, in agreement with the Minister of Finance and the Minister of Infrastructure and the Environment, establishing procedural provisions regarding the application for certifying institution of qualified signature creation devices, the application for the status of qualified and regarding the trust list, to repeal of the Electronic Signatures Regulation and the Trust List Scheme and amending a number of regulations as a result of the entry into force of the eIDAS Regulation.

Register holder

A government body that collects and records data in a register. The register holder is responsible in this for definition and specification of registration and the design of storage and communication facilities to enable reuse. The register holder should satisfy a number of minimum requirements, but also has the freedom to make certain choices in this area. Mostly a register holder also registers other data regarding the objects of which it has established the identity.

Registration Authority – RA

An entity within the responsibility of the TSP. A Registration Authority processes certificate requests and all accompanying tasks in which the verification of the identity of the certificate holder is the most important. The RA has a clear relationship with one or more Certification Authorities: The RA gives - following verification - the assignment to the Certification Authorities for the production of certificates. An RA can, at the same time function for more than one Certification Authority.

Registration service

A service that verifies the identity and, if appropriate, other specific characteristics of a subscriber. The results of this are forwarded to the Certificate Generation Service.

Request for Comments - RFC

A proposal for a standard originating from the IETF. Although an RFC does not have the formal status of a standard, in practice the RFCs as a rule are followed.

Reseller

A person or entity that has been given consent from the TSP to sell PKI certificates to subscribers on behalf of the TSP.

Revocation management service

A service that handles and reports requests that concern the revocation of certificates in order to determine the measures to be taken. The results are distributed via the Revocation Status Service.

Revocation service

A TSP service in which it revokes certificates when: agreements end; errors in the certificate are ascertained; or a private key is compromised that belongs to the public key included in the certificate. The revoked certificates are included in the Certificate Revocation List.

Revocation status information

Information that is needed to demonstrate the validity of a certificate. This information can be made available for example via an Online Certificate Status Protocol or Certification Revocation Lists.

Revocation status service

A service that supplies this certificate information about the revocation status to relying parties. This service can be a real-time service but can also be based on revocation status information that is updated at regular intervals.

Race Integrity Primitives Evaluation Message Digest - RIPEMD

A one-way Hash function. The number of bits of the hash value that flows from this is mostly displayed immediately afterwards. In this way the much used RIPEMD-160 delivers a 160 bit output.

Rivest-Shamir-Adleman algorithm – RSA algorithm

A cryptographic method that uses a double key. The private key is retained by the owner; the public key is published. Data is encrypted with the public key of the recipient and can only be decrypted with the private key of the recipient. The RSA algorithm is calculation intensive which means it is often used to make a digital envelope, that contains an RSA encrypted DES key and with DES encrypted data.

Root (NL: Stam)

The central part of a (PKI) hierarchy to which the entire hierarchy and its security level is attached.

Root Certification Authority – Root-CA (NL: Stam-Certification Authority – Stam-CA)

A Certification Authority that is the centre of the joint trust in a PKI hierarchy. The CA certificate from the Root-CA is self-signed, which means that it is not possible to authenticate the source of the signature on this certificate, only the integrity of the content of the certificate. The Root CA however is trusted because someone else has said so or because people have read the CP and any other documents and found these to be satisfactory.

Root signing

Signing a certificate of the Root CA by the Root CA itself. See also the diagram under “Hierarchical model”.

Secure Hash Algorithm - SHA

A certain algorithm that gives a concrete addition to a Hash function. The still much used SHA 1 was developed by the American government and produces a Message Digest of 160 bits. The Advanced Encryption Standard and SHA-2 are successors of this.

Secure Multi-Purpose Internet Mail Extensions – S/MIME

A secure method for sending e-mail. The e-mail clients of both Netscape as well as Microsoft support S/MIME. MIME, as described in RFC 1521, describes how an electronic message needs to be organized. S/MIME describes how encryption information and a certificate can be added as component of the text from the message. S/MIME follows the syntax given in the PKCS#7 document. S/MIME presupposes a PKI for electronic signing of email messages and for the support of encryption of messages and attachments.

S/MIME capable certificate

Within the context of the PKIoverheid PoR/CP, this refers to a publicy trusted legacy certificate (Organization Person, Organization Services or Citizen) that is techincally capable of being used to encrypt email messages or digitally sign them. These certificates MUST both contain the emailProtection EKU and have a valid email adress included in the subject.altname.rfc822name extension.

Secure Signature Creation Device - SSCD (NL: Veilig middel voor het aanmaken van elektronische handtekeningen)

A tool for producing electronic signatures that satisfies the requirements according to article 18.17, first paragraph of the Telecommunications Act. [Electronic Signatures Act]

The Citizen domains in the PKI for the government has chosen for the smartcard as SSCD. In Government/Companies and Organization domains both smartcards as well as USB tokens can be used, if these meet the requirements.

Secure Sockets Layer - SSL

A protocol created by Netscape to manage the security of message sending in a network and give access to web services. The word sockets refers in this to the method of sending data back and forth between a client and a server programme in a network or between programme layers in the same computer.

Secure User Device – SUD (NL: Veilig gebruikersmiddel)

A tool that contains the user’s private key(s), protects the key(s) against compromise and implements electronic signing, authentication or decrypting on behalf of the user.

Security Function - SF

One or more parts of a TOE on which it should be possible to rely on a closely-related partial collection of Certificate Policy regulations regarding enforcing the TOE.

Security policy

The collection of regulations, set down by the security authority, to organize the use and measures regarding security services and facilities.

Self-signed certificate

A certificate for a Certification Authority, signed by that Certification Authority itself. This can only be for a root certificate of a hierarchy.

Services certificate

A certificate with which a function or device, for example a server is linked to a legal person or different organization. In the case of a server, the certificate is used for safeguarding the connection between a certain client and the server that belongs to the organizational entity that is described as subscriber in the certificate concerned. A services certificate is not a qualified certificate.

Session key

A symmetric key that is used once for a message e-messaging or a telephone discussion (a session). After the end of the e-messaging or the telephone conversation, the key is discarded.

Signature creation data (NL: Gegevens voor het aanmaken van elektronische handtekeningen)

Unique data, such as codes or cryptographic private keys that are used by the signatory to produce an electronic signature. [European Directive]

Signature Creation Device - SCD (NL: Middel voor het aanmaken van elektronische handtekeningen)

Configured software or hardware that is used to implement data for producing electronic signatures. [Electronic Signatures Act]

Signature verification data (NL: Gegevens voor het verifiëren van een elektronische handtekening)

Data, such as codes or cryptographic public keys used to verify an electronic signature. [European Directive]

Signature Verification Device – SVD (NL: Middel voor het verifiëren van een elektronische handtekening)

Configured software or hardware that is used to implement data for verifying electronic signatures. [European Directive]

Signing key (NL: Tekensleutel)

The private key that is used to place an electronic signature. A distinction can be made between a signing key from a Certification Authority and a signing key from an end user. The end user places his electronic signature with the signing key. The signing key from the Certification Authority is used to sign such things as the certificates issued and to sign the Certificate Revocation List.

Single Sign-On - SSO

A procedure in which only one authentication is needed per session, which means that it is not necessary for end users to authenticate for different applications within one session.

Key monitoring services

The generation, storage, issue or destruction of cryptographic key material that is used to produce or verify electronic signatures. [Statutory regulation electronic signature]

Explanation: Key monitoring services can be implemented by a TSP or (partly) by the certificate holder itself. The concept ‘key monitoring service’ is not used separately in the context of the PKI for the government.

Key pair

In an asymmetric cryptographic system, this is a private key and is mathematically connected to the public key. This has the property that a public key can be used to verify an electronic signature made with a private key. In the case of encryption, this property means that information that is encrypted with public key can be decrypted with the private key (or vice versa).

Smartcard

A plastic card, the size of a credit card that contains an electronic chip, including a microprocessor, memory space and a feed source. The cards can be used to save information and can be carried easily. In the future, the electronic Dutch Identity Card (eNIK) will be a smartcard.

Root certificate (NL:Stamcertificaat)

The certificate of the Root-CA. This is the certificate that belongs to the place from which the trust in all certificates issued by the PKI for the government originate. This certificate is signed by the holder’s CA (within the PKI for the government, this is the PA PKIoverheid). All underlying certificates are issued by the holder of the root certificate. See also the diagram under “Hierarchical model”.

Sponsor-validated certificate

A certificate which links a natural person with an organisational entity. Formely also known as organisation-linked and in version 4.11 and earlier issued under PoR parts 3a and 3i.

Strength of Function - SOF

A qualification of a TOE security function that expresses the minimum measures deemed necessary to disconnect the security behaviour of that function through a direct attack on its underlying security mechanisms.

Subject Device Provision Service

A service required if the TSP provides the generation of private and public keys on SSCDs. In that case the Subject Device Provision Service prepares the delivery of SSCDs and implements these and also supplies the private keys to end users in such a way that the confidentiality of this is not compromised and the issue to the intended end users is guaranteed.

Subordinate CA – Sub CA

A Certification Authority that is part of a Trust Service Provider or that operates under the responsibility of the Trust Service Provider. For the PKI for the government the certificate of the Sub CA is signed with the signing key from the TSP Certification Authority. See further “Certification Authority” and also the figure “Hierarchical model”.

Target of Evaluation - TOE

A product or system including the corresponding documentation that is subjected to an evaluation.

PKIoverheid Task Force

The project organization realized by the ‘PKI for the government’. The PKIoverheid Task Force concluded its activities on 31 December 2002.

Time Stamping Authority – TSA

An entity that provides proof of existence at a specific date at a certain time.

Time Stamping Service – TSS

A TSP service that guarantees that data are produced and sent at a certain date and time.

Time stamping unit

A collection of hardware and software that is maintained as a whole and has one single Time Stamping Signing key active at a random moment.

Access Control List– ACL (NL: Toegangscontrolelijst - ACL)

A list that indicates who has rights of access to the various components of a PKI system. The list is a form of authorization.

A TCL is mainly used to control who has access to files and directories on a web server and a directory server.

Token

A secure piece or hardware or software in which the private keys of the end user are stored. A hardware token can also implement cryptographic calculations. Examples of hardware tokens are a smartcard and a USB token.

Trusted Third Party - TTP

See “Trust Service Provider”.

Trust List

A list of trusted certificates or trusted Certification Authorities.

USB token

A USB token is a token comparable to a smartcard, but has a different form. It is a medium on which certificates are stored. The difference is that for a USB token, an extra smartcard reader does not need to be installed. Conversely, it is not possible to include end user characteristics on the USB token, such as a photo or personal data.

Validity data (NL: Geldigheidsgegevens)

Additional data, collected by the signatory and/or the controlling party invited to check the accuracy and validity of an electronic signature in order to satisfy the requirements of the Certificate Policy.

Verifier

An entity that checks the correctness and validity of an electronic signature. This can be both a relying party as well as a third party that is interested in the validity of an electronic signature.

Confidentiality of Business Information

The guarantee that data actually and finally arrive with the person for whom they are intended, without that someone else can decrypt these. Outside the private sector the term “exclusivity” is also used.

Confidentiality certificate

A certificate in which the public key from the key pair is certificated that is used for confidentiality services.

Relying Party (NL:Vertrouwende partij)

A natural person or legal personality who is the recipient of a certificate and operates in trust on the certificate.

Virtual Private Network - VPN

A technology with which a logically-separated network can be built on a generally accessible physical network. The technology is currently used a lot to make possible secure teleworking or flexible working.

Voluntary accreditation (E:Vrijwillige accreditatie)

A permit in which the rights and obligations concerning the provision of certification services are reported and that, on the request of the involved trust service provider, are issued by the public or private government body taxed with recording and maintaining rights and obligations, when the certification services provider cannot exercise the rights flowing from the permit as long as the decision from the government body has not been received. [European Directive]

Implementation EU regulation electronic identities and trust services

Act of 21 December 2016 amending the Telecommunications Act, Books 3 and 6 of the Civil Code, the General Administrative Law Act and related amendments to other laws relating to the implementation of EU Regulation electronic identities and trust services.

Compulsory Identification Act (WID)

The Compulsory Identification Act (WID: Wet op Identificatieplicht) states which proof of identity can be used to determine the identity of persons.

What Is Presented Is What You See – WIPIWYS

A description of the qualities required from the interface that unambiguously delivers the end user’s message consistently with the end user’s message.

What You See Is What You Sign - WYSIWYS

A description of the interface’s required qualities that unambiguously guarantees what an end user sees on his screen for signing is also that which is provided with his electronic signature.

White card

A card (particularly a smartcard) that is not yet provided with printing or key material.

X.509

An ISO standard that defines a basic electronic format for certificates.

1.6.3 Abbreviations

The following abbreviations apply within the document “Programme of Requirements” and the definition list. Where the abbreviated term requires explanation, this explanation is included in the definition list. These terms are indicated in italics.

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1 Repositories

2.1-pkio1

Description

The maximum period of time within which the availability of the dissemination service has to be restored is set at 24 hours.

Comment

-

Applicable to

All certificates

2.1-pkio2

Description

There MUST be an electronic repository where the information referred to in Section 2.2 is published. This repository can be managed by the TSP or by an independent organization.

Comment

The information that has to be published is included in ETSI EN 319 411-1.

Applicable to

All certificates

2.2 Publication of certification information

2.2-pkio3

Description

The CPS MUST be available in English. If a CPS is published in multiple languages there MUST be no substantial substantive difference between the different versions. In case of interpretation disputes related to CPS texts the English language version SHALL always be leading.

Comment

-

Applicable to

All certificates

2.2-pkio5

Description

The TSP has to include the OIDs of the CPs that are used in the CPS.

Comment

-

Applicable to

All certificates

2.2-pkio156

Description

The CPS (or CPSs) must be reviewed or renewed yearly.

The TSP must demonstrate a renewal 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.

Comment

-

Applicable to

All certificates

2.2-pkio168

Description

The TSP MUST describe in its CPS which validation methods for validating IP addresses and / or FQDNs it uses for inclusion in the subject:commonName field, the subjectAltName:dNSName field and / or the subjectAltName:iPAdress field with a reference to the relevant chapter of the Baseline Requirements OR a reference to the number provided by the PA in the event of custom validation methods as described in requirement 3.2.5-pkio162.

Comment

-

Applicable to

• Private Server certificates (previously 3h)

2.2-pkio191

Description

The CPS of the TSP MUST follow the layout according to RFC 3647. All sections and subsections as defined in RFC 3647 MUST be included in the CPS. Empty passages are not allowed. If there is no further requirement or explanation from a TSP for that paragraph, the text “No stipulation” MUST be included. Additional sections may be included, as long as they come after the sections and subsections defined by RFC 3647 and therefore do not change the RFC numbering.

Comment

-

Applicable to

• 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
• Server 2020 certificates (previously 3j)

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

3.1.1-pkio10

Description

The TSP has to fulfil the requirements laid down for name formats in the Certificate, CRL and OCSP profiles.

Comment

Included in the Appendix of this PoR are the different Certificate, CRL and OCSP profiles.

Applicable to

All certificates

3.1.2 Need for names to be meaningful

No stipulation.

3.1.3 Anonymity or pseudonymity of subscribers

3.1.3-pkio11

Description

Pseudonyms MUST NOT be used in certificates.

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 Organization Person certificates
• G3 2023 Citizen certificates
• G3 2023 S/MIME certificates (Individual-validated and Sponsor-validated only)
• Private Person certificates (previously 3i)

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

3.2.1-pkio13

Description

The TSP is responsible for ensuring that the subscriber supplies the certificate signing request (CSR) securely. The secure delivery must take place in the following manner:

• the entry of the CSR on the TSP’s application developed especially for that purpose, using an SSL connection with a PKIoverheid SSL certificate or similar or;
• the entry of the CSR on the HTTPS website of the TSP that uses a PKIoverheid SSL certificate or similar or;
• sending the CSR by e-mail, along with a qualified electronic signature of the certificate manager that uses a PKIoverheid qualified certificate or similar or;
• entering or sending a CSR in a way that is at least equivalent to the aforementioned ways.

Comment

-

Applicable to

• G3 Legacy Organization Services certificates (previously 3b)
• G3 2023 Organization Services certificates
• G3 2023 S/MIME certificates (Organization-validated only)
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Server 2020 certificates (previously 3j)

3.2.2 Authentication of organization identity

3.2.2-pkio4

Description

The TSP has to verify that the subscriber is an existing organization.

Comment

-

Applicable to

• G3 Legacy Organization Services certificates (previously 3b)
• G3 2019 Autonomous Devices certificates (previously 3d)
• G3 2023 Organization Services certificates
• G3 2023 S/MIME certificates (Organization-validated only)
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Server 2020 certificates (previously 3j)

3.2.2-pkio14

Description

When issuing organization-linked certificates the TSP has to verify that the subscriber is an existing organization.

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 2023 Organization Person certificates
• G3 2023 S/MIME certificates (Sponsor-validated only)
• Private Person certificates (previously 3i)

3.2.2-pkio16

Description

In terms of organization-linked certificates, the TSP has to verify that the name of the organization registered by the subscriber that is incorporated in the certificate is correct and complete.

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 2023 Organization Person certificates
• G3 2023 S/MIME certificates (Sponsor-validated only)
• Private Person certificates (previously 3i)

3.2.2-pkio144

Description

The TSP has to verify that the name of the organization registered by the subscriber that is incorporated in the certificate is correct and complete.

Comment

-

Applicable to

• G3 Legacy Organization Services certificates (previously 3b)
• G3 2019 Autonomous Devices certificates (previously 3d)
• G3 2023 Organization Services certificates
• G3 2023 S/MIME certificates (Organization-validated only)
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Server 2020 certificates (previously 3j)

3.2.2-pkio186

Description

If an organization changes its name but the underlying registration number (e.g. HRN) remains the same, then the subscriber DOES NOT have to go through the subscription registration again. If the organization name remains the same but the underlying registration number changes, then the TSP MUST perform the subscription registration again.

In both cases, the existing certificate must be withdrawn because the data in the certificate no longer conforms to the originally validated data.

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Organization Services certificates (previously 3b)
• G3 2019 Autonomous Devices certificates (previously 3d)
• G3 2023 Organization Person certificates
• G3 2023 Organization Services certificates
• G3 2023 S/MIME certificates (Organization-validated and Sponsor-validated only)
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Private Person certificates (previously 3i)
• Server 2020 certificates (previously 3j)

3.2.3 Authentication of individual identity

3.2.3-pkio21

Description

When issuing certificates to natural persons the TSP has to verify that the full name used by the certificate holder that is incorporated in the certificate is correct and complete, including the surname, first forename, initials or other forename(s) (if applicable) and surname prefixes (if applicable).

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 Organization Person certificates
• G3 2023 Citizen certificates
• G3 2023 S/MIME certificates (Individual-validated and Sponsor-validated only)
• Private Person certificates (previously 3i)

3.2.3-pkio22

Description

In accordance with Dutch legislation and regulations, the TSP has to check the identity and, if applicable, specific properties of the certificate manager. Proof of identity has to be verified based on the physical appearance of the person himself, either directly or indirectly, using means by which the same certainty can be obtained as with personal presence. The proof of identity can be supplied on paper or electronically.

Comment

-

Applicable to

• G3 Legacy Organization Services certificates (previously 3b)
• G3 2019 Autonomous Devices certificates (previously 3d)
• G3 2023 Organization Services certificates
• G3 2023 S/MIME certificates (Organization-validated only)
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Server 2020 certificates (previously 3j)

3.2.3-pkio24

Description

The identity of the certificate manager can only be established using the valid documents referred to in article 1 of the Compulsory Identification Act (Wet op de identificatieplicht). The TSP has to check the validity and authenticity of these documents.

Comment

If the personal identity of the certificate manager is verified when a certificate is requested in the Government, Companies and Organization Domains, then the identity verification of the certificate manager will be considered to have taken place under this CP.

Applicable to

• G3 Legacy Organization Services certificates (previously 3b)
• G3 2019 Autonomous Devices certificates (previously 3d)
• G3 2023 Organization Services certificates
• G3 2023 S/MIME certificates (Organization-validated only)
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Server 2020 certificates (previously 3j)

3.2.3-pkio26

Description

The certificate manager is a person whose identity has to be established in conjunction with an organizational entity. Proof has to be submitted of:

• full name, including surname, first name, initials or other first (names) (if applicable) and surname prefixes (if applicable);
• date of birth and place of birth, a nationally applicable registration number, or other characteristics of the certificate manager that can be used in order to, as far as possible, distinguish this person from other persons with the same name;
• proof that the certificate manager is entitled to receive a certificate for a certificate holder on behalf of the legal personality or other organizational entity.

Comment

-

Applicable to

• G3 Legacy Organization Services certificates (previously 3b)
• G3 2019 Autonomous Devices certificates (previously 3d)
• G3 2023 Organization Services certificates
• G3 2023 S/MIME certificates (Organization-validated only)
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Server 2020 certificates (previously 3j)

3.2.4 Non-verified subscriber information

No stipulation.

3.2.5 Validation of authority

3.2.5-pkio29

Description

In terms of organization-linked certificate holders, the TSP has to check that:

• the proof that the certificate holder, authorized to receive a certificate on behalf of the subscriber, is authentic;
• the name and identity markers mentioned in this proof correspond with the certificate holder’s identity established under 3.2.3-pkio21.

In terms of profession-linked certificate holders, the TSP has to check that:

• the proof, that the certificate holder is authorised to practise the recognized profession, is authentic;
• the name and identity markers mentioned in this proof correspond with the certificate holder’s identity established under 3.2.3-pkio21.

Comment

Only considered to be authentic proof for practising a recognized profession is:

• either a valid proof of registration in a (professional) register recognized by the relevant professional group, to which disciplinary rules stipulated by law apply;
• or an appointment by a Minister;
• or valid proof (e.g. a permit) that the legal requirements in relation to practising a profession, are fulfilled;
• or an appointment by a municipal official or mayor (only in case of municipal tax bailiff).

Understood to be meant by valid proof is proof that has not expired or that has not (temporarily or provisionally) been revoked.

PoR requirement 3.2.5-pkio160 contains a limitative list of the professions referred to under the first three bullets.

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 2023 Organization Person certificates
• Private Person certificates (previously 3i)

3.2.5-pkio30

Description

The TSP has to verify that:

• the proof that the certificate holder is authorized to receive a certificate on behalf of the subscriber, is authentic;
• the certificate manager has received permission from the subscriber to perform the actions that he has been asked to perform (if the certificate manager performs the registration process).

Comment

The “certificate manager” who takes over those actions from the certificate holder does not necessarily have to be the same person as the system administrator or personnel officer. Also the knowledge of the activation data of the key material (for example PIN) can be shared by various people if the organization of the certificate management requires that. However, it is recommended that as few people as possible have knowledge of the PIN. It also would be wise to take measures that limit access to the PIN. An example of this is placing the PIN in a safe to which only authorized persons can gain access in certain situations.

Applicable to

• G3 Legacy Organization Services certificates (previously 3b)
• G3 2023 Organization Services certificates
• G3 2023 S/MIME Certificates (Organization-validated only)
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Server 2020 certificates (previously 3j)

3.2.5-pkio31

Description

The TSP has to verify that:

• the proof that the certificate holder is authorized to receive a certificate on behalf of the subscriber, is authentic;
• the certificate manager has received the consent of the subscriber to perform the actions that he has been asked to perform (if the certificate manager performs the registration process).
• the requested certificate in combination with the permanently stored data in the certificate holder (device) contain information to be able to trace the following unequivocally:
  • the device’s identity (e.g. manufacturer and serial number);
  • the proof that the device and its production process conform to the framework of standards established by the party responsible for establishing the framework.

Comment

The “certificate manager” who takes over those actions from the certificate holder does not necessarily have to be the same person as the person who produces or uses the certificate holder (the device). Also the knowledge of the activation data of the key material (for example PIN) can be shared by various people if the organization of the certificate management requires that. However, it is recommended that as few people as possible have knowledge of the PIN. It would also be wise to take measures that restrict access to the PIN. An example of this is placing the PIN in a safe to which only authorized persons can gain access in certain situations.

Applicable to

• G3 2019 Autonomous Devices certificates (previously 3d)

3.2.5-pkio32

Description

Subscriber is a legal personality (organization-linked certificates):

The agreement that the TSP enters into with the subscriber has to state that the subscriber is responsible for immediately informing the TSP of any relevant changes that have been made to the relationship between the subscriber and the certificate holder, by means of a revocation request. Relevant changes can, in this respect, for instance be termination of employment and suspension.

Subscriber is a natural person (occupation-linked certificates):

The agreement that the TSP enters into with the subscriber has to state that the subscriber is responsible for immediately informing the TSP of any relevant changes that have been made by means of a revocation request. A relevant change in this respect is, in any case, no longer having legal proof as outlined in 3.2.5-pkio29.

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 2023 Organization Person certificates
• G3 2023 S/MIME certificates (Sponsor-validated only)
• Private Person certificates (previously 3i)

3.2.5-pkio33

Description

The agreement that the TSP enters into with the subscriber has to state that the subscriber is responsible for immediately informing the TSP of any relevant changes to the relationship between the subscriber and certificate manager and/or service. When the service no longer exists, this has to take place by means of a revocation request.

Comment

-

Applicable to

• G3 Legacy Organization Services certificates (previously 3b)
• G3 2023 Organization Services certificates
• G3 2023 S/MIME certificates (Organization-validated only)
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Server 2020 certificates (previously 3j)

3.2.5-pkio34

Description

The agreement that the TSP enters into with the subscriber has to state that the subscriber is responsible for immediately informing the TSP of any relevant amendments to the relation between the subscriber and certificate manager and/or certificate holder (autonomous device). If the device fails, this has to be done using a revocation request.

Comment

-

Applicable to

• G3 2019 Autonomous Devices certificates (previously 3d)

3.2.5-pkio146

Description

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

Comment

A High Risk Certificate Request is a 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.

Applicable to

• Private Server certificates (previously 3h)
• Server 2020 certificates (previously 3j)

3.2.5-pkio160

Description

Regulated Profession Certificates SHALL be issued only to subscribers 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 this URL: 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.

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 2023 Organization Person certificates
• Private Person certificates (previously 3i)

3.2.5-pkio162

Description

If an FQDN is included in the certificate, the TSP MUST check whether the FQDNs supplied by the subscriber (see definition in Part 4), included in a certificate, are:

• Actually in the name of the subscriber OR;
• Authorized by the registered domain owner OR;
• That the subscriber can show that it exercises (technical) control over the FQDN in question.

The verified data may be reused in a subsequent application, provided that it is not older than 39 months. If the data is older than 39 months, the above check must be carried out again

This must be done for every FQDN that is included in a certificate. The TSP must limit itself to:

• the methods as prescribed in the applicable version of the TLS Baseline Requirements of the CA/B Forum (Section 3.2.2.4) OR;
• an alternative method approved in advance by the PA.

The TSP must also keep a record of the validation method (s) used for the included FQDNs per certificate.

This verification may not be outsourced by the TSP to external (sub) contractors.

Comment

-

Applicable to

• Private Server certificates (previously 3h)

3.2.5-pkio170

Description

The TSP MUST check whether the FQDNs supplied by the subscriber (see definition in Part 4) or IP addresses, included in a certificate, are:

• Actually in the name of the subscriber OR;
• Authorized by the registered domain owner OR;
• That the subscriber can show that he exercises (technical) control over the FQDN in question.

This must be done for every FQDN that is included in a certificate. The TSP must limit itself to the methods as prescribed in the applicable version of the Baseline Requirements of the CABForum (chapter 3.2.2.4 for FQDNs and 3.2.2.5 for IP addresses).

The foregoing also holds that “Any Other Method” from 3.2.2.5 may not be used (for both 3.2.2.4.8 and for IP addresses).

The verified data may be reused in a subsequent application, provided that it is no older than 398 days. If the data is older than 398 days, the above check must be carried out again.

The TSP must also keep a record of the validation method (s) used for the included FQDNs per certificate. This verification may not be outsourced by the TSP to external (sub) contractors.

Comment

-

Applicable to

• Server 2020 certificates (previously 3j)

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

3.3.1-pkio36

Description

ETSI EN 319 411-1 GEN-6.3.6-10 is only allowed for encryption certificates. For all other types of PKIoverheid certificates a re-key MUST take place when renewing a certificate.

Comment

ETSI EN 319 411-1 GEN-6.3.6-10 states under which conditions recertification of the keys of encryption certificates is permitted. The requirement means that certificates CANNOT be renewed without a re-key for the authenticity, signature and server certificates.

Applicable to

All certificates

3.3.1-pkio45

Description

Before certificates are renewed, it must be checked that both requirement 3.1.1-pkio and all requirements stated under Sections 3.1 and 3.2 of the CP for that type of certificate have been fulfilled.

Comment

The relevant articles in which the requirements are specified can be found in part 3 Reference matrix PKIoverheid and ETSI.

When replacing a personal certificate at the end of its lifetime the qualified signature of the non-repudiation certificate can be used during registration and identification, instead of the physical presence of the certificate holder. This is subject to a number of conditions:

• The non-repudiation certificate must be valid at the time of renewal;
• The file must be current and complete, including a copy of a valid ID document (WID);
• Subject details of the applicant of the new personal certificate are the same as the details in the valid non-repudiation certificate, e.g. organization field;
• The single renewal of the certificate without physical appearance is only possible through the TSP that issued the non-repudiation certificate based on physical identification.

All personal certificates under PoR parts 3a, 3c and 3i can be renewed once in this manner.

Applicable to

All certificates

3.3.2 Identification and authentication for re-key after revocation

3.3.2-pkio46

Description

After revocation of the certificate, the relevant keys cannot be recertified. ETSI EN 319 411-1 GEN-6.3.6-10 does not apply.

Comment

-

Applicable to

All certificates

3.4 Identification and authentication for revocation request

No stipulation.

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1 Certificate Application

4.1-pkio47

Description

Before a services server certificate is issued, the TSP must enter into an agreement with the subscriber and receive a certificate request signed by the certificate manager. The agreement must be signed by the Authorized Representative or Representation of the subscriber.

Comment

-

Applicable to

• G3 Legacy Organization Services certificates (previously 3b)
• G3 2023 Organization Services certificates
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)

4.1.1 Who can submit a certificate application

No stipulation.

4.1.2 Enrollment process and responsibilities

No stipulation.

4.2 Certificate application processing

4.2-pkio179

Description

A CA must be able to replace its total population of outstanding, still valid certificates within 5 days, provided the subscriber cooperates in a timely manner.

Comment

With “cooperation by the subscriber”, the PA means the provision of any and all data required by the TSP to process and deliver a certificate (request) such as domain validation and Certificate Signing Request (CSR).

To ensure that a subscriber is able to provide such data in a timely manner, the TSP may, for example, take the following measures:

• Setting up a customer portal that facilitates and speeds up the process;
• Periodically checking (domain) validation so that data is “fresh” at the time it is needed;
• (Partially) automating the certificate issuing process via an API (e.g. RFC 8555).

Applicable to

• Server 2020 certificates (previously 3j)

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

4.4.1-pkio49

Description

After issuance of a certificate, the certificate holder of a personal certificate or the certificate manager of the other types of certificate has to specifically confirm to the TSP the delivery of the key material that is part of the certificate.

Comment

When keys protected by software are used (see 6.2.11-pkio106 and 6.2.11-pkio107) where the private key is generated by the certificate manager rather than the TSP, the delivery of key material is not applicable. However, the data required in 7.3.1.i and 7.3.1.m must be logged. This stipulation is applicable to Private Server certificates (previously 3h) and Server 2020 certificates (previously 3j).

Applicable to

All certificates

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

4.4.3-pkio154

Description

The certificate SHALL contain at least 3 SCTs from separate Certificate Transparency logs.

The SCTs come from a log that is either qualified or awaiting qualification at the time of certificate issue. A qualified log is defined as a CT log that complies with Chromium’s Certificate Transparency Log Policy and has been included by Chromium.

SCTs have to come from at least 2 different CT log operators, AND at least one of which SHALL be Google.

Comment

-

Applicable to

• Server 2020 certificates (previously 3j)

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

4.5.2-pkio51

Description

The terms and conditions for users that are made available to the relying parties have to state that the relying party has to check the validity of the full chain of certificates up to the source (root certificate) that is relied on.

The terms and conditions must also state that the subscriber is personally responsible for prompt replacement 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.

Comment

The validity of a certificate does not indicate the certificate holder’s authority to perform a specific transaction on behalf of an organization or pursuant to his or her profession. The PKI for the government does not arrange authorization; a relying party has to convince itself of that in a different manner.

It is advisable to inform the subscriber to take into account the “ICT beveiligingsrichtlijnen voor de transport layer security (TLS)” of the NCSC when using PKIoverheid server certificates. This advice can be obtained online via the website of the NCSC.

Applicable to

All certificates

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

4.9.1-pkio52

Description

Certificates must be revoked when:

• the subscriber states that the original request for a certificate was not allowed and the subscriber does not provide consent with retrospective force;
• the TSP has sufficient proof that the subscriber’s private key (that corresponds with the public key in the certificate) is compromised or if compromise is suspected, or if there is inherent security vulnerability, or if the certificate has been misused in any other way. A key is considered to be compromised in the event of unauthorized access or suspected unauthorized access to the private key, if the private key, SSCD, SUD or QSCD, is lost or suspected to be lost, if the key, SSCD, SUD or QSCD, is stolen or suspected to be stolen, or if the key or SSCD, SUD or QSCD is destroyed;
• a subscriber does not fulfil its obligations outlined in this CP or the corresponding CPS of the TSP or the agreement that the TSP has entered into with the subscriber;
• the TSP is informed or otherwise becomes aware of a substantial change in the information that is provided in the certificate. An example of that is: a change in the name of the certificate holder;
• the TSP determines that the certificate has not been issued in line with this CP or the corresponding CPS of the TSP or the agreement that the TSP has entered into with the subscriber;
• the TSP determines that information in the certificate is incorrect or misleading;
• the TSP ceases its work and the CRL and OCSP services are not taken over by a different TSP.
• the PA of PKIoverheid determines that the technical content of the certificate entails an irresponsible risk to subscribers, relying parties and third parties (e.g. browser parties).

Comment

In addition, certificates can be revoked as a measure to prevent or to combat an emergency. Considered to be an emergency is definitely the compromise or suspected compromise of the private key of the TSP used to sign certificates.

Applicable to

• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Private Private Person certificates (previously 3i)

4.9.1-pkio192

Description

Certificates will be revoked when:

• the subscriber indicates that the original request for a certificate was not allowed and the subscriber does not grant permission retroactively;
• the TSP has sufficient evidence that the subscriber’s private key (associated with the corresponding certificate) has been compromised or there is a suspicion of compromise, inherent security weakness, or that the certificate has been misused in another way . A key is considered compromised in the event of unauthorized access or suspected unauthorized access to the private key, lost or presumably lost private key, SSCD, SUD or QSCD, stolen or presumably stolen key, SSCD, SUD or QSCD or destroyed key, SSCD, SUD or QSCD if applicable;
• a subscriber does not fulfill his obligations as set out in this CP or the corresponding CPS of the TSP or the agreement that the TSP has with the subscriber;
• the TSP is informed or otherwise becomes aware of a material change in the information contained in the certificate. An example of this is: change of the name of the certificate holder (service);
• the TSP determines that the certificate has not been issued in accordance with this CP or the associated CPS of the TSP or the agreement that the TSP has with the subscriber;
• the TSP determines that information in the certificate is incorrect or misleading;
• the TSP ceases its activities and the CRL and OCSP services are not continued by another TSP;
• the PA of PKIoverheid determines that the technical content of the certificate entails an irresponsible risk for subscribers, relying parties and third parties (e.g. browser parties);
• one of the events occurs, as described in chapter 6.2 of the Mozilla Root Store Policy.

Comment

-

Applicable to

• 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

4.9.1-pkio193

Description

Certificates will be revoked when:

• the subscriber indicates that the original request for a certificate was not allowed and the subscriber does not grant permission retroactively;
• the TSP has sufficient evidence that the subscriber’s private key (associated with the corresponding certificate) has been compromised or there is a suspicion of compromise, or there is an inherent security weakness, or that the certificate has been misused in another way . A key is considered compromised in the event of unauthorized access or suspected unauthorized access to the private key, lost or presumably lost private key, SSCD, SUD or QSCD, stolen or presumably stolen key, SSCD, SUD or QSCD or destroyed key, SSCD, SUD or QSCD if applicable;
• a subscriber does not meet his obligations as set out in this CP or the corresponding CPS of the TSP or the agreement that the TSP has concluded with the subscriber;
• the TSP is informed or otherwise becomes aware of a material change in the information contained in the certificate. An example of this is: change of the name of the certificate holder (service);
• the TSP determines that the certificate has not been issued in accordance with this CP or the associated CPS of the TSP or the agreement that the TSP has concluded with the subscriber;
• the TSP determines that information in the certificate is incorrect or misleading;
• the TSP ceases its activities and the CRL and OCSP services are not continued by another TSP;
• the PA of PKIoverheid determines that the technical content of the certificate entails an irresponsible risk for subscribers, relying parties and third parties (e.g. browser parties).
• one of the events occurs, as described in chapter 6.2 of the Mozilla Root Store Policy. The TSP must adhere to the revocation deadlines as stated in chapter 6.1 of the previous document.

Comment

-

Applicable to

• Server 2020 certificates (previously 3j)

4.9.2 Who can request revocation

4.9.2-pkio53

Description

The following parties can request revocation of an end user certificate:

• the certificate manager;
• the certificate holder;
• the subscriber;
• the TSP;

any other party or person that has an interest, at the discretion of the TSP.

Comment

-

Applicable to

All certificates

4.9.3 Procedure for revocation request

4.9.3-pkio55

Description

The maximum period of time within which the availability of the revocation management services have to be restored is set at four hours.

Comment

-

Applicable to

All certificates

4.9.3-pkio56

Description

The TSP has to record the reasons for revocation of a certificate if the revocation is initiated by the TSP.

Comment

-

Applicable to

All certificates

4.9.3-pkio57

Description

In any case, the TSP has to use a CRL to make the certificate status information available.

Comment

-

Applicable to

All certificates

4.9.4 Revocation request grace period

No stipulation.

4.9.5 Time within which CA must process the revocation request

4.9.5-pkio61

Description

The maximum delay between receiving a revocation request or revocation report and the amendment of the revocation status information that is available to all relying parties, is set at four hours.

Comment

This requirement applies to all types of certificate status information (CRL and OCSP).

Applicable to

All certificates

4.9.6 Revocation checking requirement for relying parties

No stipulation.

4.9.7 CRL issuance frequency (if applicable)

4.9.7-pkio65

Description

The TSP has to update and reissue the CRL for end user certificates at least once every 7 calendar days and the date of the “Next update” field may not exceed the date of the “Effective date” field by 10 calendar days.

Comment

-

Applicable to

• 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
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Private Private Person certificates (previously 3i)

4.9.8 Maximum latency for CRLs (if applicable)

No stipulation.

4.9.9 On-line revocation/status checking availability

4.9.9-pkio66

Description

The revocation management services of the TSP can support the Online Certificate Status Protocol (OCSP) as an addition to the publication of CRL information. If this support is available, this has to be stated in the CPS.

Comment

If OCSP is offered the following requirements are applicable:

• 1.1-pkio10 (basic requirement)
• 9.5-pkio61 (basic requirement)
• 9.9-pkio67
• 9.9-pkio68
• 9.5-pkio69 (basic requirement)
• 9.9-pkio70
• 9.9-pkio71
• 10.2-pkio73 (basic requirement)

NB: (EV) server certificates MUST use OCSP services as stipulated in ETSI EN 319 411-1 and the Baseline Requirements.

Applicable to

• 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 Private Person certificates (previously 3i)

4.9.9-pkio67

Description

If the TSP supports the Online Certificate Status Protocol (OCSP), this must conform to IETF RFC 6960.

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Organization Services certificates (previously 3b)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 Organization Person certificates
• G3 2023 Organization Services certificates
• G3 2023 Citizen certificates
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Private Private Person certificates (previously 3i)

4.9.9-pkio68

Description

To detail the provisions of IETF RFC 6960, OCSP responses have to be signed digitally by either:

• the private (CA) key with which the certificate is signed of which the status is requested, or;
• a responder appointed by the TSP which holds an OCSP Signing certificate issued for this purpose by the TSP, or;
• a responder that holds an OCSP Signing certificate that falls under the hierarchy of the PKI for the government.

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 Organization Person certificates
• G3 2023 Citizen certificates
• Private Private Person certificates (previously 3i)

4.9.9-pkio69

Description

To detail the provisions in IETF RFC 6960, the use of precomputed OCSP responses is not allowed.

Comment

-

Applicable to

All certificates

4.9.9-pkio70

Description

If the TSP supports OCSP, the information that is provided through OCSP has to be at least as equally up-to-date and reliable as the information that is published by means of a CRL, during the validity of the certificate that is issued and furthermore up to at least six months after the time at which the validity of the certificate has expired or, if that time is earlier, after the time at which the validity is ended by revocation.

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Organization Services certificates (previously 3b)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 Organization Person certificates
• G3 2023 Organization Services certificates
• G3 2023 Citizen certificates
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Private Private Person certificates (previously 3i)
• Server 2020 certificates (previously 3j)

4.9.9-pkio71

Description

If the TSP supports OCSP, the TSP has to update the OCSP service at least once every 4 calendar days. The maximum expiry term of the OCSP responses is 10 calendar days. In addition OCSP responses must contain the nextUpdate field in conformance to RFC 6960.

Comment

-

Applicable to

• 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
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Private Private Person certificates (previously 3i)

4.9.9-pkio152

Description

If the TSP supports OCSP, the OCSP response must have a minimum validity of 8 hours and a maximum validity of 7 calendar days. The next update must be available no later than half of the validity of an OCSP response.

Comment

-

Applicable to

• Server 2020 certificates (previously 3j)

4.9.10 On-line revocation checking requirements

No stipulation.

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

4.9.13-pkio72

Description

Suspension of a certificate MUST NOT be supported.

Comment

-

Applicable to

All certificates

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

4.10.2-pkio73

Description

The maximum period of time within which the availability of the revocation status information has to be restored is set at four hours.

Comment

This requirement only applies to the CRL and not to other mechanisms, such as OCSP.

Applicable to

All certificates

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

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

5.2-pkio74

Description

The TSP has to reperform the risk analysis at least every year, or if the PA provides an instruction to that end, or the NCSC provides advice to that end. The risk analysis has to cover all PKIoverheid processes that fall under the responsibility of the TSP.

Based on the risk analysis, the TSP has to develop, implement, maintain, enforce and evaluate an information security plan. This plan describes a cohesive framework of appropriate administrative, organizational, technical and physical measures and procedures with which the TSP can safeguard the availability, exclusivity and integrity of all PKIoverheid processes, requests and the information that is used to this end.

Comment

-

Applicable to

All certificates

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

5.2.4-pkio76

Description

The TSP has to enforce separation of duties between at least the following roles:

• Security officer
  • The security officer is responsible for the implementation of and compliance with the stipulated security guidelines.
• System auditor
  • The system auditor fulfils a supervisory role and provides an independent opinion on the manner in which the business processes are arranged and on the manner in which the requirements relating to security are fulfilled.
• Systems administrator
  • The systems manager maintains the TSP systems, which includes installing, configuring and maintaining the systems.
• TSP operators
  • The TSP operators are responsible for the everyday operation of the TSP systems for, among other things, registration, the generation of certificates, the delivery of an SSCD to the certificate holder and revocation management.

Comment

The aforementioned job descriptions are not limitative and the TSP is free to extend the description within the requirements of segregation of functions, or to divide the functions further still, or to share these between other trusted officials.

5.2.4-pkio77

Description

The TSP has to enforce separation of duties between staff who monitor the issuance of a certificate and staff who approve the issuance of a certificate.

Comment

-

5.3 Personnel controls

5.3-pkio78

Description

Because publication of confidential information can have significant consequences (among other things, for the trustworthiness) the TSP has to make every effort to make sure that confidential information is dealt with confidentially and that it remains confidential. One important aspect is to ensure that declarations of confidentiality are signed by staff members and contracted third parties.

Comment

-

Applicable to

All certificates

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

5.4.1-pkio80

Description

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 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 Certificates do have merit for the whole PKIoverheid ecosystem. Therefore, certain sections are adopted in full as general PoR requirements.

Applicable to

All certificates

5.4.2 Frequency of processing log

No stipulation.

5.4.3 Retention period for audit log

5.4.3-pkio81

Description

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.
• TSPs will have a grace period of three months after the publication date of PoR 4.12 for implementing this requirement. During this grace period TSP may use the version of this requirement as it is stipulated in PoR 4.11. THIS NOTE WILL BE REMOVED IN PoR 4.13.

Applicable to

All certificates

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

5.5.1-pkio82

Description

The TSP MUST archive all information used to verify the identity of the subscriber, certificate manager and applicants of revocation requests. This information includes reference numbers of the documentation used for verification, including limitations concerning the validity.

Comment

-

Applicable to

• G3 Organization Person certificates (previously 3a)
• G3 Organization Services certificates (previously 3b)
• G3 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 Private Person certificates (previously 3i)
• Server 2020 certificates (previously 3j)

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

Description

In the event of a security breach and/or emergency the TSP has to immediately inform the PA, the NCSC, the Agentschap Telecom (AT) and the certifying body (CB). In case of the loss of privacy sensitive information the Autoriteit Persoonsgegevens (AP) must also be informed. After analysis the TSP has to keep the PA, the NCSC, AT and the CB informed about how the incident is progressing.

Comment

Understood to be meant by security breach in the PKIoverheid context is:

An infringement of the TSP core services: registration service, certificate generation service, subject device provisioning service, dissemination service, revocation management service and revocation status service. This is including, but not limited to:

• unauthorized elimination of a core service or rendering this core service inaccessible;
• unauthorized access to a core service in order to eavesdrop on, intercept and/or change electronic messaging;
• unauthorized access to a core service for unauthorized removal, amendment or alteration of computer data.

Applicable to

All certificates

5.7.1-pkio85

Description

The TSP will inform the PA immediately about the risks, dangers or events that can in any way threaten or influence the security of the services and/or the image of the PKI for the government. This is including, but not limited to security breaches and/or emergencies relating to other PKI services performed by the TSP, which are not PKIoverheid services.

Comment

-

Applicable to

All certificates

5.7.1-pkio181

Description

The PA obliges the TSP to subscribe to the NCSC security advice to be knowledgeable about dangers or events that can in threaten or influence the security of the services and/or the image of the PKI for the government.

Comment

-

Applicable to

All certificates

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

5.7.4-pkio86

Description

The TSP has to draw up a business continuity plan (BCP) for, at the very least, the core services dissemination service, revocation management service and revocation status service, the aim being, in the event of a security breach or emergency, to inform, reasonably protect and to continue the TSP services for subscribers, relying parties and third parties (including browser parties). The TSP has to test, assess and update the BCP annually. At the very least, the BCP has to describe the following processes:

• Requirements relating to entry into force;
• Emergency procedure/fall-back procedure;
• Requirements relating to restarting TSP services;
• Maintenance schedule and test plan that cover the annual testing, assessment and update of the BCP;
• Provisions in respect of highlighting the importance of business continuity;
• Tasks, responsibilities and competences of the involved agents;
• Intended Recovery Time or Recovery Time Objective (RTO);
• Recording the frequency of back-ups of critical business information and software;
• Recording the distance of the fall-back facility to the TSP’s main site; and
• Recording the procedures for securing the facility during the period following a security breach or emergency and for the organization of a secure environment at the main site or fall-back facility.

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Organization Services certificates (previously 3b)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 Organization Person certificates
• G3 2023 Organization Services certificates
• G3 2023 Citizen certificates
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Private Private Person certificates (previously 3i)

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

Description

The keys of certificate holders (or data for creating electronic signatures) have to be generated using a device that fulfils the requirements mentioned in ETSI EN 419 211 for QSCDs or CWA 14169 for SSCDs (transitional permission regime) “Secure signature-creation devices ‘EAL 4+’” or comparable security criteria.

Comment

-

Applicable to

• 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

6.1.1-pkio89

Description

The algorithm and length of the cryptographic keys that the TSP uses to generate the keys of certificate holders must meet the requirements set in the list of cryptographic algorithms and key lengths, as defined in ETSI TS 119 312. In addition, the TSP must also follow the requirements described in Chapters 5.1, 5.1.1 and 5.1.2 of the most current Mozilla Root Store Policy (MRSP). The use of RSA-PSS is permitted, but is not recommended.

Comment

Although ETSI TS 119 312 outlines the recommended algorithms and key lengths, these are compulsory within the PKI for the government. Requests relating to the use of other algorithms have to be submitted, along with the reasoning behind this, to the PA of the PKI for the government.

Applicable to

All certificates

6.1.1-pkio90

Description

The generation of key pairs the certificate holder’s key by the TSP is not allowed.

Comment

-

Applicable to

Server 2020 certificates (previously 3j)

6.1.1-pkio91

Description

If the TSP generates the private key for the subscriber, this MUST be supplied encrypted to the subscriber to safeguard the integrity and confidentiality of the private key. The following measures must then be taken into account:

• The TSP MUST generate the private key for the subscriber in the secured environment to which the PKIoverheid PoR and the corresponding audit apply;
• Once the private key has been generated for the subscriber, it MUST be stored encrypted using a strong algorithm (in accordance with the requirements of ETSI TS 119 312) within the TSP’s secured environment;
• When storing this key, the TSP MUST apply the P12 standard, where the privacy mode and the integrity mode are used. To this end, the TSP MAY encrypt the P12 file with a personal PKI certificate of the subscriber/certificate manager. If this is not available, the TSP MUST use a password supplied by the subscriber. This password MUST be supplied by the subscriber through the TSP’s website, for which an SSL/TLS connection is used, or via a similar procedure which guarantees the same trustworthiness and security;
• If a password is used to encrypt the P12, this password has to contain at least 8 positions including at least one number and two special characters;
• The TSP MAY NEVER send the password that is used to encrypt/decrypt the P12 in cleartext over a network or store it on a server. The password MUST be encrypted using a strong algorithm (in accordance with the requirements of ETSI TS 119 312);
• The P12 file MUST be sent to the subscriber over an SSL/TLS secured network, or be supplied out-of-band on a data carrier (e.g. USB stick).
• If the P12 is supplied out-of-band, this must be additionally encrypted with a key other than the P12 file. In addition, the P12 MUST be delivered to the subscriber using a certified courier, or by a representative of the TSP in a seal bag. The courier must be certified in accordance with the requirements dictated in part 2 under paragraph 2.2 for the specific service applicable here.
• If the P12 file is sent over a SSL/TLS secured network the TSP MUST ensure that the P12 file is successfully downloaded no more than once. Access to the P12 file when transferring via SSL/TLS has to be blocked after three attempts.

Comment

Best practice is that the subscriber himself generates the private key that belongs to the public key. When the TSP generates the private key belonging to the public key on behalf of the subscriber, this has to fulfil the aforementioned requirements. When generating the key, it is important to realize that not only is the P12 file encrypted, but that the access to the P12 file is secured when the transfer is made.

Applicable to

• Private Server certificates (previously 3h)

6.1.1-pkio92

Description

A TSP within PKIoverheid is not allowed to issue code signing certificates.

Comment

-

Applicable to

• All certificates

6.1.1-pkio93

Description

Instead of the TSP generating the keys, the certificate manager MAY generate the keys of the services authenticity and encryption certificates in a SUD using PKCS#10 to deliver the CSR to the TSP for signing, under the following conditions:

• The agreement between the TSP and the subscriber stipulates that the certificate manager generates, saves and uses the private key on a secure device that conforms to the requirements of CWA 14169 for a Secure signature-creation devices or EN 419 211 for Qualified signature-creation devices “EAL 4+” or comparable security criteria.
• With the request the subscriber must prove that the secure device used for key generation conforms to CWA 14169 for a Secure signature-creation devices or EN 419 211 for Qualified signature-creation devices EAL 4+"" or comparable security criteria.
• The TSP must then verify that the SUD in question conforms (comparable to “The subscriber MUST prove that the organization may use this name.”).
• On registration the certificate manager must at least produce a written statement that measures have been taken in the environment of the system that generates/contains the keys. The measures must be of such quality that is practically impossible to steal or copy the keys unnoticed.
• The agreement between the subscriber and the TSP must stipulate that the TSP has the right to perform an audit on the measures taken (conform 6.2.11-pkio107).
• The agreement between the subscriber and the TSP must contain the following condition. The subscriber must declare that the private key (and the corresponding access information such as a PIN code), relating to the public key in het SUD in question has, in an appropriate manner, been generated under the control of the certificate manager and will be kept secret and protected in the future.

Comment

-

Applicable to

• G3 Legacy Organization Services certificates (previously 3b)
• G3 2023 Organization Services certificates
• Private Organization Services certificates (previously 3g)

6.1.1-pkio153

Description

Subject key generation of a qualified digital seal certificate for the use of mass automated signing of standardised data is allowed in ETSI 319 411-2. ETSI does not stipulate the applicable security requirements. Subject key generation within PKIoverheid is possible under the following conditions:

The contract between the TSP and the subscriber contains an assertion that the subscriber will generate, store and use the private key on a qualified device for electronic signatures – such as a HSM – which meets the requirements of {7} CWA 14169 Secure signature-creation devices or EN 419 211 for Qualified signature-creation devices “EAL 4+” or equivalent security criteria such as FIPS 140-2 level 3.

The subscriber shall hand over evidence to this effect with the certificate request by submitting the certification of the secure device and, if applicable, a screenshot of the settings of the secure device on FIPS140-2 level 3.

• The contract between the TSP and the subscriber contains an assertion in which the subscriber states that the private key (and associated activation data, such as a PIN code) related to the public key is generated in the qualified device and is kept secret and protected in future.
• The subscriber shall hand over evidence to this effect of the PKI ceremony script which is used during the implementation of the qualified device for electronic signatures and the generation of the key pair.
• The TSP is present during the PKI ceremony for the commissioning of the qualified device for electronic signatures and the generation of the key pair. This enables the TSP to check the effectiveness of the security measures.
• During registration the Subscriber submits a written statement of demonstrably satisfying the requirements and/or conditions placed either on the use of the qualified device for electronic signatures, or by the certification of the device on the environment in which it is administrated and the administration itself.
• The Subscriber submits a written statement that the certificate holder has explicitly mandated the system administrators of the qualified device for electronic signatures for the administration and that access to this device is always subject to dual control.

Comment

If the de TSP generates the key pair and the certificate and distributes these to the subscriber on a secure device it is not necessary to be present at the ceremony.

Applicable to

• G3 Legacy Organization Services certificates (previously 3b)
• G3 2023 Organization Services certificates

6.1.2 Private key delivery to subscriber

6.1.2-pkio94

Description

For authenticity and non-repudiation certificates, the certificate holder’s private key has to be delivered to the certificate holder, if required through the subscriber, in a manner such that the secrecy and the integrity of the key is not compromised and, once delivered to the certificate holder, the private key can be maintained under the certificate holder’s sole control.

Comment

This text corresponds with ETSI EN 319 411-1 SDP 6.3.3-09, but has been integrated because this requirement only applies to signature and authenticity certificates.

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 Organization Person certificates
• G3 2023 Citizen certificates
• Private Person certificates (previously 3i)

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

6.1.5-pkio96

Description

The length of the certificate holders’ cryptographic keys have to fulfil the requirements laid down in that respect in the list of cryptographic algorithms and key lengths as defined in ETSI TS 119 312.

Comment

Although ETSI TS 119 312 outlines the recommended algorithms and key lengths, these are compulsory within the PKI for the government. Requests relating to the use of other algorithms have to be submitted, along with the reasoning behind this, to the PA of the PKI for the government.

Applicable to

All certificates

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

6.2.3-pkio98

Description

Escrow by the TSP is not allowed for the private keys of PKIoverheid certificates, with the exception of encryption certificates.

Comment

-

Applicable to

All certificates

6.2.3-pkio99

Description

The authorized persons who can gain access to the private key of the confidentiality certificate held in Escrow by the TSP (if applicable), have to identify themselves using the valid documents listed in article 1 of the Compulsory Identification Act (Wet op de identificatieplicht), or a valid qualified certificate (limited to a PKIoverheid signature certificate or equivalent).

Comment

-

Applicable to

All certificates

6.2.3-pkio100

Description

The TSP has to describe in the CPS which parties can have access to the private key of the confidentiality certificate held in Escrow and under which conditions.

Comment

-

Applicable to

All certificates

6.2.4 Private key backup

6.2.4-pkio102

Description

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

Comment

-

Applicable to

All certificates

6.2.5 Private key archival

6.2.5-pkio103

Description

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

Comment

-

Applicable to

All certificates

6.2.6 Private key transfer into or from a cryptographic module

No stipulation.

6.2.7 Private key storage on cryptographic module

No stipulation.

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

6.2.11-pkio104

Description

Secure devices issued or recommended by the TSP for creating electronic signatures (SSCDs or QSCDs) have to fulfil the requirements laid down in document CWA 14169 “Secure signature-creation devices or EN 419 211 for Qualified signature-creation devices ‘EAL 4+’” and the requirements outlined in or pursuant to the Electronic Signatures Decree article 5, parts a, b, c and d.

Comment

The use of different types of secure devices, such as a smartcard or a USB key, is allowed. The condition is that the SSCD or QSCD meets the substantive requirements as specified in 6.2.11-pkio104, 6.2.11-pkio105 and 6.2.11-pkio106.

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 Organization Person certificates
• G3 2023 Citizen certificates
• Private Person certificates (previously 3i)

6.2.11-pkio105

Description

Instead of demonstrating compliance with CWA 14169 (for SSCD’s or SUDs) or ETSI EN 419 211 (for QSCDs), TSPs can issue or recommend SSCDs, SUDs or QSCDs that are certified in line with a different protection profile against the Common Criteria (ISO/IEC 15408) at level EAL4+ or that have a comparable security level. This has to be established by a test laboratory that is accredited for performing Common Criteria evaluations.

Comment

-

Applicable to

All certificates

6.2.11-pkio106

Description

The concurrence of SSCDs or QSCDs with the requirements outlined in PKIo requirement 6.2.11-pkio104 has to have been ratified by a government body appointed to inspect the secure devices, for the creation of electronic signatures in accordance with the Dutch Telecommunications Act (TW) article 18.17, third paragraph. In this respect, also see the Ruling on Electronic Signatures, articles 4 and 5.

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 Organization Person certificates
• G3 2023 Citizen certificates
• Private Private Person certificates (previously 3i)

6.2.11-pkio107

Description

Instead of using a hardware-based SUD, the keys of a services certificate can be protected by software if compensating measures are taken in the system’s environment that contains the keys. The compensating measures must be of such a quality that it is practically impossible to steal or copy the key unnoticed.

When registering, the manager of the services certificates that uses this option for software-based storage has, at the very least, to submit a written declaration to state that compensating measures have been taken that fulfil the condition stipulated to this end. The agreement between the subscriber and TSP must state that the TSP is entitled to check the measures that have been taken.

Comment

Examples of compensating measures to be considered are a combination of physical access security, logical access security, logging and audit and segregation of functions.

Applicable to

• Private Server certificates (previously 3h)
• Server 2020 certificates (previously 3j)

6.2.11-pkio125

Description

Secure devices issued or recommended by the TSP for storage of keys (SUDs) have to fulfil the requirements laid down in document CWA 14169 “Secure signature-creation devices ‘EAL 4+’”.

Comment

-

Applicable to

• G3 Legacy Organization Services certificates (previously 3b)
• G3 2019 Autonomous Devices certificates (previously 3d)
• G3 2023 Organization Services certificates
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Server 2020 certificates (previously 3j)

6.3 Other aspects of key pair management

6.3.1 Public key archival

6.3.1-pkio108

Description

The signature certificate has to be saved during the term of validity and furthermore during a period of at least seven years after the date on which the validity of the certificate expired.

Comment

The Electronic Signature Regulation article 2, paragraph 1i stipulates a term of seven years for non-repudiation certificates. No further provisions apply to the authenticity certificate and the confidentiality certificate in relation to archiving public keys.

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2019 Autonomous Devices certificates (previously 3d)
• G3 2023 Organization Person certificates
• G3 2023 Citizen certificates

6.3.2 Certificate operational periods and key pair usage periods

6.3.2-pkio109

Description

Private keys that are used by a certificate holder and issued under the responsibility of this CP must not be used for more than five years. The certificates, which are issued under the responsibility of this CP, must not be valid for more than five years.

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Organization Services certificates (previously 3b)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 Organization Person certificates
• G3 2023 Organization Services certificates
• G3 2023 Citizen certificates

6.3.2-pkio110

Description

At the time that an end user certificate is issued, the remaining term of validity of the higher level TSP certificate has to exceed the intended term of validity of the end user certificate.

Comment

-

Applicable to

All certificates

6.3.2-pkio111

Description

Private keys that are used by a certificate holder and issued under the responsibility of this CP must not be used for more than ten years. The certificates, which are issued under the responsibility of this CP, must not be valid for more than ten years.

Comment

The TSPs within the Autonomous Devices domain of the PKI for the government cannot issue certificates with a maximum term of validity of ten years until the PA has provided explicit permission for this.

Applicable to

• G3 2019 Autonomous Devices certificates (previously 3d)

6.3.2-pkio178

Description

Private keys used by a certificate holder and issued under the responsibility of this CP MAY NOT be used for more than two (2) years.

Certificates issued under the responsibility of this CP MAY NOT be valid for more than 397 days.

In the event that a certificate is replaced following revocation under section 4.9.1.1 of the Baseline Requirements, the private key of a certificate MAY NOT be reused, except in the case of revocation under point 7 (certificate not issued in accordance with BR or CP/CPS of TSP).

Comment

-

Applicable to

• Server 2020 certificates (previously 3j)

6.4 Activation data

6.4.1 Activation data generation and installation

6.4.1-pkio112

Description

The TSP attaches activation data to the use of a SUD, SSCD or QSCD, to protect the private keys of the certificate holders.

Comment

The requirements that the activation data (for example the PIN code) have to fulfil can be determined by the TSPs themselves based on, for example, a risk analysis. Requirements that could be considered are the length of the PIN code and use of special characters.

Applicable to

All certificates

6.4.1-pkio113

Description

An unlocking code can only be used if the TSP can guarantee that, at the very least, the security requirements are fulfilled that are laid down in respect of the use of the activation data.

Comment

-

Applicable to

All certificates

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

6.5.1-pkio114

Description

The TSP has to use multi-factor authentication (e.g. smartcard with personal certificates and a personal password or biometry and a personal password) for the system or all user accounts which are used to issue or approve certificates. This is also mandatory for systems or the user accounts with which data validation takes place.

The TSP may waive this measure for systems or user accounts with which data validation takes place, provided that it has implemented technical measures, as a result of which a user account can only validate certificate requests on the basis of a pre-approved list of domains or e-mail addresses.

Comment

Multi-factor authentication tokens cannot be connected permanently or semi-permanently to the system (e.g. a permanently activated smartcard). That is because this would enable certificates to be issued or approved (semi) automatically, or for non-authorized staff to issue or approve certificates.

Applicable to

All certificates

6.5.1-pkio115

Description

The staff of external Registration Authorities (RA) or Resellers may not have access to the system or the user accounts of the TSP which enables issuance or approval of certificates. This function is restricted to authorized staff of the TSP. If an RA or a Reseller does have this access, the RA or the Reseller will be seen as part of the TSP and it/they have to comply with the PKI for the government Programme of Requirements fully and demonstrably.

Comment

-

Applicable to

All certificates

6.5.1-pkio116

Description

The TSP SHALL prevent unauthorized access to the following core services:

• registration service,
• certificate generation service,
• subject device provision service,
• dissemination service,
• revocation management service,
• revocation status service.

To this end, these core services are separated either

• physically or logically from the non-PKI network domains, or
• physically or logically from the PKI network domains that do not meet the Network Security Guidelines of the CA/B Forum, or
• physically or logically from the PKI network domains that do not meet the network related PKIoverheid requirements from RFC 3647 paragraph 6, “Technical Security Controls”.

The TSP enforces a unique authentication for each core service mentioned above.

When the physical or logical separation of the network domains described above is not feasible, the various core services must be implemented on separate network domains, where there has to be a unique authentication for each core service mentioned above.

The TSP must document the organization of the network domains, at least in a graphical manner.

This requirement does not apply to other environments, such as acceptance and test.

Comment

-

Applicable to

All certificates

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

6.7-pkio119

Description

Using an audit tool, at least each month the TSP performs a security scan on its PKIoverheid infrastructure. The TSP documents the result of every security scan and the measures that were taken in relation to this scan.

Comment

Some examples of commercial and non-commercial audit tools are GFI LanGuard, Nessus, Nmap, OpenVAS and Retina.

Applicable to

All certificates

6.7.1 Network security controls (duplicate)

6.7.1-pkio118

Description

The TSP has to ensure that all PKIoverheid ICT systems relating to the registration service, certificate generation service, subject device provision service, dissemination service, revocation management service and revocation status service:

• are equipped with the latest updates, and
• the web application controls and filters all input by users, and
• the web application codes the dynamic output, and
• the web application maintains a secure session with the user, and
• the web application uses a database securely.

Comment

The TSP should at a bare minimum check against the top ten web security vulnerabilities published and updated regularly by the Open Worldwide Application Security Project (OWASP) Foundation, which is commonly referred to as the OWASP Top Ten. In addition to this, it is recommended that the TSP checks against all other recommendations from the OWASP Web Security Testing Guide (WSTG).

Applicable to

All certificates

6.7.1-pkio120

Description

At least once a year, the TSP arranges for a penetration test to be performed on the PKIoverheid internet facing environment, by an independent, experienced, and competent external supplier.

In addition a TSP is obliged to arrange a pen test to be performed when substantial changes to the internet facing environment have occurred,

• The assessment if substantial changes have occurred takes place by means of a documented risk analysis.
• The pen test is performed by an independent, experienced, and competent pen tester.
• The pen test must take place no later than one month after the release, but preferably before going to production.

The TSP has to document the findings from the pen tests mentioned above and the measures that will be taken in this respect, or to arrange for these to be documented.

If necessary, the PA can instruct the TSP to perform additional pen tests.

Comment

CLARIFICATION

Substantial changes include:

• New software;
• New version of existing software, excluding patches;
• Changes in infrastructuur.

As guidance for the selection of suppliers, the TSP can use the recommendation in chapter 4 (“Supplier Selection”) as described in the latest version of the whitepaper entitled “Pentesten doe je zo” (EN: “How to perform pentesting”) published by the NCSC.

Applicable to

All certificates

6.7.1-pkio185

Description

For web application(s) related to:

• the registration service,
• certificate generation service,
• subject device provision service,
• dissemination service,
• revocation management service and
• revocation status service

the TSP must secure the following:

• That the web application checks and filters all user input and;
• That the web application encodes the dynamic output and;
• That the web application maintains a secure session with the user and;

That the web application uses a database in a secure way.

Comment

The TSP can use the “ICT-Beveiligingsrichtlijnen voor Webapplicaties” of the NCSC as guidance.

Applicable to

All certificates

6.8 Time-stamping

No stipulation.

7. CERTIFICATE, CRL, AND OCSP PROFILES

7.1 Certificate profile

7.1-pkio121

Description

The TSP has to issue certificates in accordance with the requirements stipulated in that respect in the Appendix of this document for that type of certificate, namely “Certificate profiles”. Only those certificate elements which are mentioned in the certificate profile may be used. Usage of ny and all other elements is prohibited.

Comment

-

Applicable to

All certificates

7.1-pkio149

Description

The certificate extension extendedKeyUsage SHALL be present, and its critical field SHALL be FALSE.

The keyPurposeId value in the extendedKeyUsage extension of certificates

• under the G3 Legacy Organization Person, G3 Legacy Organization Services, G3 Legacy Citizen, G3 2019 Autonomous Devices, Private Organization Services, and Private Person domains
  • with the Authenticity profile
    • SHALL contain
      • id-kp-clientAuth (OID: 1.3.6.1.5.5.7.3.2), and
      • szOID_KP_DOCUMENT_SIGNING (OID: 1.3.6.1.4.1.311.10.3.12), and
    • MAY contain
      • emailProtection (OID: 1.3.6.1.5.5.7.3.4), and
  • with the non-repudiation (eSignatures and eSeals) profile
    • SHALL contain
      • szOID_KP_DOCUMENT_SIGNING (OID: 1.3.6.1.4.1.311.10.3.12), and
    • MAY contain
      • emailProtection (OID: 1.3.6.1.5.5.7.3.4), and
  • with the confidentiality profile
    • SHALL contain
      • szOID_EFS_CRYPTO (OID: 1.3.6.1.4.1.311.10.3.4), and
    • MAY contain
      • emailProtection (OID: 1.3.6.1.5.5.7.3.4), and
  • with the Autonomous Devices combination profile
    • SHALL contain
      • id-kp-clientAuth (OID: 1.3.6.1.5.5.7.3.2),
      • szOID_KP_DOCUMENT_SIGNING (OID: 1.3.6.1.4.1.311.10.3.12), and
      • szOID_EFS_CRYPTO (OID: 1.3.6.1.4.1.311.10.3.4), and
    • MAY contain
      • emailProtection (OID: 1.3.6.1.5.5.7.3.4), and
• under the G3 2023 Organization Person, Organization Services, and Citizen domains,
  • with the Authenticity profile
    • SHALL contain
      • id-kp-clientAuth (OID: 1.3.6.1.5.5.7.3.2),
      • id-kp-documentSigning (OID: 1.3.6.1.5.5.7.3.36), and
      • szOID_KP_DOCUMENT_SIGNING (OID: 1.3.6.1.4.1.311.10.3.12), and
  • with the non-repudiation (eSignatures and eSeals) profile
    • SHALL contain
      • szOID_KP_DOCUMENT_SIGNING (OID: 1.3.6.1.4.1.311.10.3.12), and
      • id-kp-documentSigning (OID: 1.3.6.1.5.5.7.3.36), and
  • with the confidentiality profile
    • SHALL contain
      • szOID_EFS_CRYPTO (OID: 1.3.6.1.4.1.311.10.3.4), and
        
• under the G3 2023 S/MIME Individual-validated, G3 2023 S/MIME Organization-validated, and G3 2023 S/MIME Sponsor-validated domains
  • with any profile
    • SHALL contain
      • emailProtection (OID: 1.3.6.1.5.5.7.3.4), and
• under the G3 Server 2020 and Private Server domains
  • with any profile:
    • SHALL contain
      • id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1), and
      • id-kp-clientAuth (OID: 1.3.6.1.5.5.7.3.2).

The above should take into account the EKU keyPurposeId values included in the Issuing TSP Certificate: if the Issuing TSP Certificate does not contain one of the keyPurposeId stated above, then this specific keyPurposeId SHALL NOT be included in the end-user certificate.

Comment

-

Applicable to

All certificates

7.1-pkio163

Description

Subscriber certificates SHALL contain the subjectAltName extension with 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).

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 just one Base Domain Name and sub-domains thereof, or
• exceed 5 when these instances consist of mixed Base Domain Names.

Additionally, subscriber certificates SHOULD NOT contain the subject:commonName field.

If present, the subject:commonName field SHALL contain a Fully-Qualified Domain Name that is one of the values contained in the dNSNAme attribute of the Certificate’s subjectAltName extension which SHALL NOT be in U-label encoding.

Comment

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.

Applicable to

• Server 2020 certificates (previously 3j)

7.1-pkio165

Description

Subscriber certificates MAY contain the extensions:subjectAltName extension with 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).

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 just one Base Domain Name and sub-domains thereof, or
• exceed 5 when these instances consist of mixed Base Domain Names.

Additionally, subscriber certificates SHOULD NOT 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
• SHALL be controlled by the Subject or it has been granted the right to use it by the IP address assignee, and
• SHALL NOT be a Reserved IP Address.

Additionally, subscriber certificates MAY contain the subject:commonName field.

The value of the subject:commonName field 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 and 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.

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

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

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

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.

Applicable to

• Private Server certificates (previously 3h)

7.1-pkio171

Description

From ETSI TS 119 312, the TSP MUST choose from 1 of the following options for the signature field in a certificate:

• sha256WithRSAEncryption: 1.2.840.113549.1.1.11 ( OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } )
• ecdsa-with-SHA256: 1.2.840.10045.4.3.2 ( OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } )
• sha384WithRSAEncryption: 1.2.840.113549.1.1.12 ( OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } )
• ecdsa-with-SHA384: 1.2.840.10045.4.3.3 ( OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } )

Comment

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.

Applicable to

• Server 2020 certificates (previously 3j)

7.1-pkio172

Description

The Authority Information Access field must contain the following entries:

• Access Method = id-ad-ocsp (On-line Certificate Status Protocol - 1.3.6.1.5.5.7.48.1). This field must contain the URI where the OCSP responder can be found that is authorized by the issuing CA of the certificate to be checked;
• Access Method = id-ad-caIssuers (Certification Authority Issuer - 1.3.6.1.5.5.7.48.2). This field must contain the URI where the certificate of the issuing CA can be found.

Comment

-

Applicable to

• Server 2020 certificates (previously 3j)

7.1-pkio173

Description

The serial number of all end-user certificates must meet the following requirements:

1. The value of the serial number MUST NOT be 0 (zero);
2. The value of the serial number MUST NOT be negative;
3. The value of the serial number MUST be unique within the population of end-user certificates issued under an issuing TSP CA;
4. The serial number MUST have a minimum length of 96 bits (12 octets);
5. The value of the serial number MUST contain at least 64 bits of unpredictable random data;
6. Said random data MUST be generated by a Cryptographically Secure Pseudorandom Number Generator (CSPRNG);
7. The serial number MUST NOT be longer than 160 bits (20 octets).

Comment

-

Applicable to

• 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
• Server 2020 certificates (previously 3j)

7.1-pkio174

Description

All elements within the issuer field must match the corresponding subject field of the issuing CA.

Comment

-

Applicable to

All certificates

7.1-pkio177

Description

The serialNumber of all end-user certificates must meet the following requirements:

1. The value of the serial number MUST NOT be 0 (zero)
2. The value of the serial number MUST NOT be negative
3. The value of the serial number MUST be unique within the population of end-user certificates issued under an issuing TSP CA.
4. The serial number MUST have a minimum length of 96 bits (12 octets)
5. The value of the serial number MUST contain at least 64 bits of unpredictable random data
6. Said random data SHOULD be generated by a Cryptographically Secure Pseudorandom Number Generator (CSPRNG).
7. The serial number MUST NOT be longer than 160 bits (20 octets).

Comment

-

Applicable to

• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Private Person certificates (previously 3i)

7.1-pkio182

Description

The extensions:certificatePolicies extension MUST contain the following fields and values:

• policyIdentifier field with value “2.16.528.1.1003.1.2.5.9”;
• policyQualifiers:policyQualifierId field with value id-qt 1 (RFC 5280);
• policyQualifiers:qualifier:cPSuri field with value the HTTP URL for the TSP’s Certification Practice Statement.

Comment

Usage of the extensions:certificatePolicies:policyQualifiers:qualifier:userNotice field is prohibited by the CA/Browser Forum.

This requirement was also in use in the now defunct PoR part 3e. The policyIdentifier field in part 3e had a different value: 2.16.528.1.1003.1.2.5.6.

Applicable to

• Server 2020 certificates (previously 3j)

7.1-pkio202

Description

The PKIoverheid certificate profile MAY contain an 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) [1.3.6.1.4.1.311.20.2.3], or
• IA5String [1.3.6.1.4.1.1466.115.121.1.26] (but [2.5.5.5] MAY also be used for legacy purposes), or
• Permanent Identifier [1.3.6.1.5.5.7.8.3] (as defined in RFC 4043).

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

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.

Applies to

• 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
• Private Organization Services certificates (previously 3g)
• Private Server certificates (previously 3h)
• Private Person certificates (previously 3i)

7.1-pkio203

Description Subscriber certificates SHALL contain the subject:commonName field.

The value of the subject:commonName field SHALL be in either one of the following two formats, the components of which SHALL be validated against a legal identification document (see: Article 1 of the “Wet op de identificatieplicht”):

• [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 = compulsory part, style in accordance with the used legal identification document,
• text in italic = compulsory part, choice from two options (full forenames or initials), and
• normal text = optional part; if present, the style has to be the same as in the used legal identification document,

and the use of nickname is advised against.

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

ETSI standard 319 412-2 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. commonName 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.”

However, the purpose of a certificate is to be an attestation of the identity of the owner of a private key. A TSP enables this attestation through trustworthy verification processes. If a field is introduced with no verification whatsoever, a security risk is introduced in the PKI ecosystem because most people will not read the terms of use or ETSI documents. If you want to create a secure ecosystem, you do not want to depend on the alertness or in-depth knowledge of your users. This is exactly why browsers stopped bothering with EV certificates: its users never bothered check the actual company behind a certificate, negating the positive effect on the ecosystem. Then why does ETSI permit its usage? Judging from the language “to maximize interoperability” this probably stems from legacy usage in big corporations. Users are used to seeing a name they know in a signature and are reluctant to see this changed. In this case ease of use has the upper hand and wins from trustworthiness. This however is something we should not aspire to within the PKIoverheid ecosystem. Therefore usage is still allowed out of legacy considerations, but advised against as a general rule. Starting from the G4 roots PKIoverheid plans on prohibiting nicknames altogether.

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 Organization Person certificates
• G3 2023 Citizen certificates
• G3 2023 S/MIME certificates (Individual-validated and Sponsor-validated only)
• Private Person certificates (previously 3i)

7.1-pkio204

Description

Subscriber certificates SHALL contain the subject:commonName field.

The value of the subject:commonName field SHALL contain the function of an organizational entity or the name by which the device or system is known.

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

-

Applicable to

• G3 Legacy Organization Services certificates (previously 3b)
• G3 2023 Organization Services certificates
• G3 2023 S/MIME certificates (Organization-validated only)
• Private Organization Services certificates (previously 3g)

7.1-pkio205:

Description

Subscriber certificates SHALL contain the subject:commonName field.

The value of the subject:commonName field SHALL contain a device number or device type number, the authoritative source of which SHALL be described in the TSP CPS.

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

-

Applicable to

• G3 2019 Autonomous Devices certificates (previously 3d)

7.1.1 Version number(s)

No stipulation.

7.1.2 Certificate extensions

No stipulation.

7.1.3 Algorithm object identifiers

No stipulation.

7.1.4 Name forms

No stipulation.

7.1.5 Name constraints

No stipulation.

7.1.6 Certificate policy object identifier

No stipulation.

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

7.2-pkio122

Description

The TSP has to issue CRLs in accordance with the requirements stipulated in that respect in the CRL and OCSP profiles Section of this document.

Comment

-

Applicable to

All certificates

7.2.1 Version number(s)

No stipulation.

7.2.2 CRL and CRL entry extensions

No stipulation.

7.3 OCSP profile

7.3-pkio123

Description

If the TSP supports the Online Certificate Status Protocol (OCSP), the TSP has to use OCSP certificates and responses in accordance with the requirements laid down in this respect in the Appendix of this document".

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Organization Services certificates (previously 3b)
• G3 Legacy Citizen certificates (previously 3c)
• 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 Private Person certificates (previously 3i)

7.3.1 Version number(s)

No stipulation.

7.3.2 OCSP extensions

No stipulation.

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

8.1 Frequency or circumstances of assessment

8.1-pkio159

Description

A TSP is required for each (annual) ETSI audit:

• to use the current version of the Overview of Requirements developed and made available by PA PKIoverheid, OR
• use an Overview of Requirements developed by the TSP itself.

This Overview of Requirement must be reviewed and approved by the PA prior to the (annual) ETSI audit for completeness. To this end, the TSP must provide the Overview of Requirements (including accompanying Statement of Applicability) to the PA prior to an audit.

If one of these conditions is not met, the PA reserves the right to refuse the audit report.

Comment

• As part of this statement, the legend must state which versions of the applicable standards have been used.
• The TSP must allow for processing time by the PA (maximum of 15 working days).
• A copy of the reviewed Overview of Requirements will be sent to the ETSI auditor.
• The Overview of Requirements is also referred to as Overview of Applicability (OoA).

Applicable to

All certificates

8.1-pkio183

Description

A TSP MUST, when requested by the PA, perform a self-assessment against the Baseline Requirements based on a template predetermined by the PA.

Comment

Mozilla requires CAs to make a comparison of their processes (via CP and CPS documents) with the BRs using a template defined by Mozilla to ensure that their processes (and practices) continue to comply with CA’s Baseline Requirements / Browser Forum.

Applicable to

• Server 2020 certificates (previously 3j)

8.2 Identity/qualifications of assessor

8.2-pkio199

Description

The TSP’s audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means 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.

Applicable to

All certificates

8.3 Assessors relationship to assessed entity

No stipulation.

8.4 Topics covered by assessment

8.4-pkio194

Description

In addition to this PoR, issuing certificates SHALL undergo an audit in accordance with the following schemes:

1. ETSI EN 319 411-1 with policy NCP+ (ETSI CP OID 0.4.0.2042.1.2, mandating usage of SSCDs) for authenticity and confidentiality certificates, and
2. ETSI EN 319 411-2 with policy QCP-n-qscd (ETSI CP OID 0.4.0.194112.1.2, mandating usage of SSCDs) for non-repudiation certificates (eIDAS eSignatures), and
3. CA/Browser Forum Network and Certificate System Security Requirements.

When an issuing certificate contains the emailProtection EKU and the start date of its audit period is in scope of the S/MIME audit requirements in the Mozilla Root Store Program (MRSP), its audit SHALL also include ETSI TS 119 411-6.

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 Organization Person certificates
• G3 2023 Citizen certificates
• Private Person certificates (previously 3i)

8.4-pkio195

Description

In addition to this PoR, issuing certificates SHALL undergo an audit in accordance with the following schemes:

1. ETSI EN 319 411-1 with policy NCP+ (ETSI CP OID 0.4.0.2042.1.2, mandating usage of SSCDs) for authenticity and confidentiality certificates, and
2. ETSI EN 319 411-2 with policy QCP-l-qscd (ETSI CP OID 0.4.0.194112.1.3, mandating usage of SSCDs) for non-repudiation certificates (eIDAS eSeals), and
3. CA/Browser Forum Network and Certificate System Security Requirements.

When an issuing certificate contains the emailProtection EKU and the start date of its audit period is in scope of the S/MIME audit requirements in the Mozilla Root Store Program (MRSP), its audit SHALL also include ETSI TS 119 411-6.

Comment

-

Applicable to

• G3 Legacy Organization Services certificates (previously 3b)
• G3 2023 Organization Services certificates

8.4-pkio196

Description

In addition to this PoR, issuing certificates SHALL undergo an audit in accordance with the following schemes:

1. ETSI EN 319 411-1 with policy NCP+ (ETSI CP OID 0.4.0.2042.1.2, mandating usage of SSCDs) for authenticity and confidentiality certificates, and
2. CA/Browser Forum Network and Certificate System Security Requirements.

Comment

-

Applicable to

• G3 2019 Autonomous Devices certificates (previously 3d)
• Private Organization Services certificates (previously 3g)

8.4-pkio197

Description

In addition to this PoR, issuing certificates SHALL undergo an audit in accordance with the following schemes:

1. ETSI EN 319 411-1 with policy NCP (ETSI CP OID 0.4.0.2042.1.1),
2. ETSI TS 119 411-6 with policy NCP (ETSI CP OID 0.4.0.2042.1.1), and
3. CA/Browser Forum Network and Certificate System Security Requirements.

Comment -

Applicable to

• G3 2023 S/MIME certificates

8.4-pkio198

Description

In addition to this PoR, issuing certificates SHALL undergo an audit in accordance with the following schemes:

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

-

Applicable to

• Private Server certificates (previously 3h)

8.4-pkio200

Description

If the TSP issues or intends to issue qualified certificates under PKIoverheid, the following additional requirements SHALL apply:

1. the audit report states that the TSP meets the eIDAS (910/2014) regulation requirements, and
2. the issuing certificate with which the TSP wants to issue qualified certificates is on the Trusted Services List (TSL) of Agentschap Telecom (AT).

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Organization Services certificates (previously 3b)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 Organization Person certificates
• G3 2023 Organization Services certificates
• G3 2023 Citizen certificates
• Private Person certificates (previously 3i)

8.4-pkio201

Description

Audits SHALL be performed against the applicable audit criteria, in the latest published version which has gone into effect, available at the commencement of the audit.

Comment

-

Applicable to

All certificates

8.5 Actions taken as a result of deficiency

No stipulation.

8.6 Communication of results

8.6-pkio158

Description

The PA informs TSPs about relevant changes to the Baseline Requirements and / or the Extended Validation Guidelines. TSPs must prove that they comply with stated changes by submitting a signed statement from or on behalf of the authorized director to the PA before the effective date of the change in question. The PA provides a template for this.

If a TSP cannot comply on time or does not submit a signed declaration on time, the PA reserves the right to (temporarily) suspend certificate issuance at the relevant TSP until the TSP can (demonstrably) comply with the stated change.

Comment

-

All certificates

• Server 2020 certificates (previously 3j)

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

9.2-pkio124

Description

By means, for example, of insurance or its financial position, the TSP has to be able to cover third party recovery based on the types of liability mentioned in article 6:196b of the Civil Code (that relate to both direct and indirect damage) up to at least EUR 1,000,000 per annum.

Comment

The third party recovery described above is based on a maximum number of certificates to be issued of 100,000 for each TSP, which is in line with the current situation. When TSPs are going to issue more certificates, it will be determined whether a suitable, higher, recoverableness will be required.

Applicable to

All certificates

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

9.5-pkio126

Description

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

Comment

-

Applicable to

All certificates

9.6 Representations and warranties

9.6.1 CA representations and warranties

9.6.1-pkio127

Description

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

Comment

-

Applicable to

All certificates

9.6.1-pkio131

Description

The TSP can include in a non-repudiation certificate restrictions with regard to the use of the certificate, provided that the restrictions are clear to third parties. The TSP is not liable for losses that results from the use of a signature certificate that is contrary to the provisions in accordance with the previous sentence listed therein.

Comment

This article is based on Civil Code art. 196b, paragraph 3.

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Organization Services certificates (previously 3b)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 Organization Person certificates
• G3 2023 Organization Services certificates
• G3 2023 Citizen certificates

9.6.1-pkio132

Description

The TSP excludes all liability for damages if the certificate is not used in accordance with the certificate use described in paragraph 1.4.

Comment

-

Applicable to

All certificates

9.6.1-pkio142

Description

In the agreement between the TSP and the subscriber, a clause (a clause as specified in article 6:253 of the Civil Code) will be included in which the TSP champions the interests of a third party relying on the certificate. This clause addresses a liability of the TSP in accordance with article 6:196b, first up to and including third paragraph, of the Civil Code, with the proviso that:

1. for “a qualified certificate specified in article 1.1, division ss Telecommunications Act”: “a confidentiality certificate from the PKIoverheid Autonomous Devices domain” is read;
2. for “signatory”: “certificate holder” is read;
3. for “creation of electronic signatures”: “creation of encrypted data” is read;
4. for “verification of electronic signatures”: “decoding of encrypted data” is read.

Comment

-

Applicable to

• G3 2019 Autonomous Devices certificates (previously 3d)

9.6.1-pkio229

Description

TSP issuing S/MIME capable certificates SHALL indicate compliance with the SBRG by inserting the following prhase 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.

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Organization Services certificates (previously 3b)
• G3 Legacy Citizen certificates (previously 3c)
• G3 2023 S/MIME certificates

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

9.8-pkio133

Description

Within the scope of certificates as mentioned in paragraph 1.4 in this CP the TSP is not allowed to place restrictions on the use of certificates.

Comment

-

Applicable to

• G3 Legacy Organization Person certificates (previously 3a)
• G3 Legacy Organization Services certificates (previously 3b)
• G3 Legacy Citizen certificates (previously 3c)
• 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)

9.8-pkio135

Description

Within the scope of certificates, as mentioned in paragraph 1.4 in this CP the TSP is not allowed to place restrictions on the value of the transactions for which certificates can be used.

Comment

-

Applicable to

All certificates

9.8-pkio143

Description

The TSP is allowed to place restrictions on the use of certificates within the scope of certificates as mentioned in paragraph 1.4 of the applicable PoR part for that type of certificate.

Comment

-

Applicable to

• G3 2019 Autonomous Devices certificates (previously 3d)

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

The change procedure for the PoR of the PKIoverheid is incorporated in PKIoverheid’s Certificate Practice Statement (CPS). The CPS can be obtained in an electronic format on the PA’s website: https://cps.pkioverheid.nl

This CP and the approved amendments made to it can be obtained in an electronic format through the Internet on the PA’s website. The address of this is: https://www.logius.nl/pkioverheid

9.13 Dispute resolution provisions

9.13-pkio138

Description

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

Comment

-

Applicable to

All certificates

9.14 Governing law

Dutch law is applicable to the CP of PKIoverheid.

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

Description

CAs MUST actively inform their subscribers at least once every six months that, according to the terms and conditions, certificates are revoked under the conditions of - and within the time limits of - the BRG requirements specified in 4.9.1.1.

Comment

-

Applicable to

• Server 2020 certificates (previously 3j)

9.17-pkio184

Description

The TSP must provide data twice a year on the total number of issued certificates and outstanding certificates in the previous period. These figures must be supplied in the format prepared and distributed for this by the PA.

Comment

-

Applicable to

All certificates

9.17-pkio190

Description

This requirement only applies if a TSP deploys CAs that are not technically contrained as described in chapter 5.3.1 in the Mozilla Root Store Policy (MRSP).

If an event occurs or threatens to occur as described in Chapter 8 of the Mozilla Root Store Policy, the TSP must:

• Inform the PA of this without delay;
• Not take (irreversible) actions without the approval of the PA;
• Take all possible actions to (permanently) meet the requirements in Chapter 8 of the aforementioned Root Store Policy.

Comment

-

Applicable to

All certificates

APPENDIX: CERTIFICATE PROFILES

For all certificate profiles in this section the following criteria codes are used for fields and attributes:

• V : Compulsory; indicates that the attribute is compulsory and MUST be used in the certificate.
• O : Optional; indicates that the attribute is optional and MAY be used in the certificate.
• A : Advised against; indicates that the attribute is advised against and SHOULD NOT be used in the certificate.
• N : Is NOT ALLOWED.

It is not allowed to use fields that are not specified in the certificate profiles.

For the extensions, fields/attributes are used that, in accordance with international standards, are critical, are marked in the ‘Critical’ column with ‘yes’ to show that the relevant attribute MUST be checked using a process by means of which a certificate is evaluated. Other fields/attributes are shown with ‘no’.

Profile for CRLs

General Requirements

• The CRLs have to fulfil the X.509v3 standard for CRLs.
• A CRL contains information about revoked certificates that fall within the current period of validity or of which the period of validity expired less than 6 months ago.

Attributes

Standard Extensions

Profile for certificates under the G3 2019 Autonomous Devices Domain

Basic attributes

Standard extensions

Private extensions

Profile for certificates under the G3 Legacy Citizen Domain

Basic attributes

Standard extensions

Private extensions

Profile for certificates under the G3 Legacy Organization Person Domain

Basic attributes

Standard extensions

Private extensions

Profile for certificates under the G3 Legacy Organization Services Domain

Basic attributes

Standard extensions

Private extensions

Profile for certificates under the G3 2023 Citizen Domain

Basic attributes

Standard extensions

Private extensions

Profile for certificates under the G3 2023 Organization Person Domain

Basic attributes

Standard extensions

Private extensions

Profile for certificates under the G3 2023 Organization Services Domain

Basic attributes

Standard extensions

Private extensions

Profile for certificates under the G3 2023 S/MIME Domain: Individual-validated only

Basic attributes

Standard extensions

Private extensions

Profile for certificates under the G3 2023 S/MIME Domain: Sponsor-validated only

Basic attributes

Standard extensions

Private extensions

Profile for certificates under the G3 2023 S/MIME Domain: Organization-validated only

Basic attributes

Standard extensions

Private extensions

Profile for certificates under the Private Organization Services Domain

Basic attributes

Standard extensions

Private extensions

Profile for certificates under the Private Server domain

Basic attributes

Standard extensions

Private extensions

Profile for certificates under the Private Persons Domain

Basic attributes

Standard extensions

Private extensions

Profile for certificates under the Server 2020 domain

Basic attributes

Standard extensions

Private extensions

Profile for OCSP Signing Certificates

General Requirements

• If the TSP supports the Online Certificate Status Protocol (OCSP), OCSP responses and OCSPSigning certificates MUST fulfil the requirements relating to this stipulated in IETF RFC 6960.
• OCSP Signing certificates MUST correspond with the X.509v3 standard for public key certificates. General requirements in relation to certificates are listed in RFC 5280
• The X.509 standard allows unlimited extension of the attributes within a certificate. In connection with interoperability requirements, this may not be used within the PKI for the government. Only attributes indicated in this appendix as Compulsory (V), Optional (O) or Advised Against (A) may be used.
• OCSP Signing certificates must fulfil the profile for services certificates set out in part 3b of the Programme of Requirements PKIoverheid, with the following exceptions:

Attributes