PKIoverheid Programme of Requirements 4.12
Table of Contents
- 1. INTRODUCTION
- 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
- 3. IDENTIFICATION AND AUTHENTICATION
- 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
- 4.1 Certificate Application
- 4.2 Certificate application processing
- 4.3 Certificate issuance
- 4.4 Certificate acceptance
- 4.5 Key pair and certificate usage
- 4.6 Certificate renewal
- 4.6.1 Circumstance for certificate renewal
- 4.6.2 Who may request renewal
- 4.6.3 Processing certificate renewal requests
- 4.6.4 Notification of new certificate issuance to subscriber
- 4.6.5 Conduct constituting acceptance of a renewal certificate
- 4.6.6 Publication of the renewal certificate by the CA
- 4.6.7 Notification of certificate issuance by the CA to other entities
- 4.7 Certificate re-key
- 4.7.1 Circumstance for certificate re-key
- 4.7.2 Who may request certification of a new public key
- 4.7.3 Processing certificate re-keying requests
- 4.7.4 Notification of new certificate issuance to subscriber
- 4.7.5 Conduct constituting acceptance of a re-keyed certificate
- 4.7.6 Publication of the re-keyed certificate by the CA
- 4.7.7 Notification of certificate issuance by the CA to other entities
- 4.8 Certificate modification
- 4.8.1 Circumstance for certificate modification
- 4.8.2 Who may request certificate modification
- 4.8.3 Processing certificate modification requests
- 4.8.4 Notification of new certificate issuance to subscriber
- 4.8.5 Conduct constituting acceptance of modified certificate
- 4.8.6 Publication of the modified certificate by the CA
- 4.8.7 Notification of certificate issuance by the CA to other entities
- 4.9 Certificate revocation and suspension
- 4.9.1 Circumstances for revocation
- 4.9.2 Who can request revocation
- 4.9.3 Procedure for revocation request
- 4.9.4 Revocation request grace period
- 4.9.5 Time within which CA must process the revocation request
- 4.9.6 Revocation checking requirement for relying parties
- 4.9.7 CRL issuance frequency (if applicable)
- 4.9.8 Maximum latency for CRLs (if applicable)
- 4.9.9 On-line revocation/status checking availability
- 4.9.10 On-line revocation checking requirements
- 4.9.11 Other forms of revocation advertisements available
- 4.9.12 Special requirements related to key compromise
- 4.9.13 Circumstances for suspension
- 4.9.14 Who can request suspension
- 4.9.15 Procedure for suspension request
- 4.9.16 Limits on suspension period
- 4.10 Certificate status services
- 4.11 End of subscription
- 4.12 Key escrow and recovery
- 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS
- 5.1 Physical controls
- 5.2 Procedural controls
- 5.3 Personnel controls
- 5.3-pkio78
- 5.3.1 Qualifications, experience, and clearance requirements
- 5.3.2 Background check procedures
- 5.3.3 Training requirements
- 5.3.4 Retraining frequency and requirements
- 5.3.5 Job rotation frequency and sequence
- 5.3.6 Sanctions for unauthorized actions
- 5.3.7 Independent contractor requirements
- 5.3.8 Documentation supplied to personnel
- 5.4 Audit logging procedures
- 5.5 Records archival
- 5.6 Key changeover
- 5.7 Compromise and disaster recovery
- 5.8 CA or RA termination
- 6. TECHNICAL SECURITY CONTROLS
- 6.1 Key pair generation and installation
- 6.2 Private Key Protection and Cryptographic Module Engineering Controls
- 6.2.1 Cryptographic module standards and controls
- 6.2.2 Private key (n out of m) multi-person control
- 6.2.3 Private key escrow
- 6.2.4 Private key backup
- 6.2.5 Private key archival
- 6.2.6 Private key transfer into or from a cryptographic module
- 6.2.7 Private key storage on cryptographic module
- 6.2.8 Method of activating private key
- 6.2.9 Method of deactivating private key
- 6.2.10 Method of destroying private key
- 6.2.11 Cryptographic Module Rating
- 6.3 Other aspects of key pair management
- 6.4 Activation data
- 6.5 Computer security controls
- 6.6 Life cycle technical controls
- 6.7 Network security controls
- 6.8 Time-stamping
- 7. CERTIFICATE, CRL, AND OCSP PROFILES
- 7.1 Certificate profile
- 7.1-pkio121
- 7.1-pkio149
- 7.1-pkio163
- 7.1-pkio165
- 7.1-pkio171
- 7.1-pkio172
- 7.1-pkio173
- 7.1-pkio174
- 7.1-pkio177
- 7.1-pkio182
- 7.1-pkio202
- 7.1-pkio203
- 7.1-pkio204
- 7.1-pkio205:
- 7.1.1 Version number(s)
- 7.1.2 Certificate extensions
- 7.1.3 Algorithm object identifiers
- 7.1.4 Name forms
- 7.1.5 Name constraints
- 7.1.6 Certificate policy object identifier
- 7.1.7 Usage of Policy Constraints extension
- 7.1.8 Policy qualifiers syntax and semantics
- 7.1.9 Processing semantics for the
critical
Certificate Policies extension
- 7.2 CRL profile
- 7.3 OCSP profile
- 7.1 Certificate profile
- 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
- 9. OTHER BUSINESS AND LEGAL MATTERS
- 9.1 Fees
- 9.2 Financial responsibility
- 9.3 Confidentiality of business information
- 9.4 Privacy of personal information
- 9.4.1 Privacy plan
- 9.4.2 Information treated as private
- 9.4.3 Information not deemed private
- 9.4.4 Responsibility to protect private information
- 9.4.5 Notice and consent to use private information
- 9.4.6 Disclosure pursuant to judicial or administrative process
- 9.4.7 Other information disclosure circumstances
- 9.5 Intellectual property rights
- 9.6 Representations and warranties
- 9.7 Disclaimers of warranties
- 9.8 Limitations of liability
- 9.9 Indemnities
- 9.10 Term and termination
- 9.11 Individual notices and communications with participants
- 9.12 Amendments
- 9.13 Dispute resolution provisions
- 9.14 Governing law
- 9.15 Compliance with applicable law
- 9.16 Miscellaneous provisions
- 9.17 Other provisions
- APPENDIX: CERTIFICATE PROFILES
- Profile for CRLs
- Profile for certificates under the G3 2019 Autonomous Devices Domain
- Profile for certificates under the G3 Legacy Citizen Domain
- Profile for certificates under the G3 Legacy Organization Person Domain
- Profile for certificates under the G3 Legacy Organization Services Domain
- Profile for certificates under the G3 2023 Citizen Domain
- Profile for certificates under the G3 2023 Organization Person Domain
- Profile for certificates under the G3 2023 Organization Services Domain
- Profile for certificates under the G3 2023 S/MIME Domain: Individual-validated only
- Profile for certificates under the G3 2023 S/MIME Domain: Sponsor-validated only
- Profile for certificates under the G3 2023 S/MIME Domain: Organization-validated only
- Profile for certificates under the Private Organization Services Domain
- Profile for certificates under the Private Server domain
- Profile for certificates under the Private Persons Domain
- Profile for certificates under the Server 2020 domain
- Profile for OCSP Signing Certificates
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.
Requirement | Unique number of the PKIoverheid requirement. |
---|---|
Description | Description of the requirement. |
Comment | To provide a better understanding of the context in which the requirement has to be placed a comment has been added to a number of PKIo requirements. |
Applicable to | The PKIoverheid certificate domain(s) this requirement is applicable to. |
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 longercritical
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
withkeyUsage
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
toissuer: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
andsubject: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
andextKeyUsage
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 theextKeyUsage
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
Version | Date | Description |
---|---|---|
1.0 | 09-11-2005 | Ratified by the Ministry of the Interior and Kingdom Relations in November 2005 |
1.1 | 25-01-2008 | Ratified by the Ministry of the Interior and Kingdom Relations in January 2008 |
1.2 | 13-01-2009 | Ratified by the Ministry of the Interior and Kingdom Relations in January 2009 |
2.0 | 09-10-2009 | Ratified by the Ministry of the Interior and Kingdom Relations October 2009 |
2.1 | 11-01-2010 | Ratified by the Ministry of the Interior and Kingdom Relations January 2010 |
3.0 | 25-01-2011 | Ratified by the Ministry of the Interior and Kingdom Relations January 2011 |
3.1 | 01-07-2011 | Ratified by the Ministry of the Interior and Kingdom Relations in June 2011 |
3.2 | 27-01-2012 | Ratified by the Ministry of the Interior and Kingdom Relations in January 2012 |
3.3 | 01-07-2012 | Ratified by the Ministry of the Interior and Kingdom Relations in June 2012 |
3.4 | 04-02-2013 | Ratified by the Ministry of the Interior and Kingdom Relations in February 2013 |
3.5 | 06-07-2013 | Ratified by the Ministry of the Interior and Kingdom Relations in July 2013 |
3.6 | 24-01-2014 | Ratified by the Ministry of the Interior and Kingdom Relations in January 2014 |
3.7 | 23-06-2014 | Ratified by the Ministry of the Interior and Kingdom Relations in June 2014 |
4.0 | 01-04-2015 | Ratified by the Ministry of the Interior and Kingdom Relations in March 2015 |
4.1 | 27-07-2015 | Ratified by the Ministry of the Interior and Kingdom Relations in July 2015 |
4.2 | 18-01-2016 | Ratified by the Ministry of the Interior and Kingdom Relations in January 2016 |
4.3 | 01-07-2016 | Ratified by the Ministry of the Interior and Kingdom Relations in June 2016 |
4.4 | 01-02-2017 | Ratified by the Ministry of the Interior and Kingdom Relations in January 2017 |
4.5 | 01-07-2017 | Ratified by the Ministry of the Interior and Kingdom Relations in June 2017 |
4.6 | 01-02-2018 | Ratified by the Ministry of the Interior and Kingdom Relationsin January 2018 |
4.7 | 08-02-2019 | Ratified by the Ministry of the Interior and Kingdom Relations in February 2019 |
4.8 | 03-02-2020 | Ratified by the Ministry of the Interior and Kingdom Relations in February 2020 |
4.9 | 01-03-2021 | Ratified by the Ministry of the Interior and Kingdom Relations in February 2021 |
4.10 | 01-03-2022 | Ratified by the Ministry of the Interior and Kingdom Relations in February 2022 |
4.11 | 28-02-2023 | Ratified by the Ministry of the Interior and Kingdom Relations in February 2023 |
4.12 | 15-01-2024 | Ratified by the Ministry of the Interior and Kingdom Relations in January 2024 |
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.
- [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
- 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.
- [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
- 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.
- [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
- 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.
- [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
- 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
- [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
- 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.
- [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
- 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
- [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
- 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.
- [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
- 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.
- [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
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
- Verifying someone’s identity before information transfer takes place.
- 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;
Organization | Authorized Representative |
---|---|
Local council | Mayor, Council Secretary |
Province | King’s Commissioner |
Ministry | Minister, Director General, Secretary General |
School | Director/Head, Secretary of the Board |
Water Board | Director (Dijkgraaf), Administrator(s) |
Care organization | Director, Administrator(s) |
Association | Administrator(s) |
LLV | Administrator(s) |
Joint-Stock Company | Administrator(s) |
Partnership | All partners or one of the partners as representative of the partnership (i.e. as representative of all partners at the same time) if this is authorized by the other partners. |
Sole Trader | Owner |
General Partnership | Each partner, who is not excluded is authorized to act ‘in the name of the partnership’ (i.e. the joint partners) |
Limited Partnership | Only active partners: they are authorized to act in the name of the limited partnership and are mainly connected for the obligations contracted in the name of the partnership |
Cooperation | Administrator(s) |
Profit and Loss Service | Director, Administrator(s) |
Independent Administrative Body (ZBO) | Director, Administrator(s) |
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:
- This is linked uniquely to the signatory;
- This enables the signatory to be identified;
- This is established using devices that the signatory can keep under its exclusive control;
- 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:
- This is linked uniquely to the signatory;
- This enables the signatory to be identified;
- This is established using devices that the signatory can keep under its exclusive control;
- This is linked in such a way to the electronic file to which it relates that every subsequent change of data can be traced;
- This is based on a qualified certificate as intended in article 1.1, part ss Telecommunications Act; and
- 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:
- for persons;
- 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,
- 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.
AA | Attribute Authority |
ACL | Access Control List |
AES | Advanced Encryption Standard |
AID | Application Identifier |
API | Application Programming Interface |
ARL | Authority Revocation List |
BM | Biometric Method |
BPR | Personal Records and Travel Documents Agency |
BSM | Biometric Sensor Unit |
CA | Certification Authority |
CC | Common Criteria |
CDSA | Common Data Security Architecture |
CEN | Comité Européen de Normalization |
CGA | Certification Generation Application |
CMS | Cryptographic Message Syntax |
CN | CommonName |
CP | Certificate Policy |
CPS | Certification Practice Statement |
CPU | Central Processing Unit |
CRA | Card Reader Application |
CRL | Certificate Revocation List |
TSP | Trust Service Provider |
CWA | CEN Workshop Agreement |
DES | Data Encryption Standard |
DN | Distinguished Name |
DPV | Dedicated Path Validation |
DS | Dissemination Service |
DSA | Digital Signature Algorithm |
DTBS | Data to be signed |
EAL | Evaluation Assurance Level |
EEMA | European Electronic Messaging Association |
EEPROM | Electronically Erasable Programmable Read Only Memory |
EESSI | European Electronic Signature Standardization Initiative |
EFT | Electronic Funds Transfers |
EN | Europese Norm (European Standard) |
eNIK | Elelectronic Dutch Identity Card |
ETSI | European Telecommunications Standards Institute |
EVCP+ | Enhanced Extended Validation Certificates Policy |
FIPS | Federal Information Processing Standard |
GBA | Municipal Basic Administration |
HSM | Hardware Security Module |
http | HyperText Transfer Protocol |
HW | Hardware |
ID | Identifier |
IDS | Intrusion Detection System |
IEC | International Electrotechnical Commission |
IETF | Internet Engineering Task Force |
IFM | Interface module |
I/O | Input/Output |
IP | Internet Protocol |
ISO | International Organization for Standardization |
KEA | Key Escrow Agency |
LCP | Lightweight Certificate Policy |
LDAP | Lightweight Directory Access Protocol |
LRA | Local Registration Authority |
MD | Message Digest |
NAP | National Action Programme Electronic Superhighway |
NCP | Normalized Certificate Policy |
NCP+ | extended Normalized Certificate Policy |
NEN | Dutch Norm |
NIST | National Institute of Standards & Technology |
NQC | Non-Qualified Certificate |
OCF | Open Card Framework |
OCSP | Online Certificate Status Protocol |
OID | Object Identifier |
OPTA | Independent Post and Telecommunications Authority |
OTAP | Develop, Test, Acceptance and Production Systems |
PA | Policy Authority |
PnP | Plug and Play |
PDA | Personal Digital Assistant |
PDS | PKI Disclosure Statement |
PIN | Personal Identification Number |
PKCS | Public Key Cryptography Standard |
PKI | Public Key Infrastructure |
POP | Proof of Possession |
PP | Protection Profile |
PRNG | Pseudo Random Number Generator / Pseudo Random Noise Generator |
PUK | Personal Unblocking Key |
QC | Qualified Certificate |
QCP | Qualified Certificate Policy |
RA | Registration Authority |
RFC | Request for Comments |
RIPEMD | Race Integrity Primitives Evaluation Message Digest |
RND | Random Number |
RNG | Random Number Generator |
RP | Relying Party |
RSA | Rivest-Shamir-Adleman algorithm |
SBRG | Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates document by the CA/Browser Forum |
SCA | Signature Creation Application |
SCD | Signature Creation Device |
SCE | Signature Creation Environment |
SF | Security Function |
SHA | Secure Hash Algorithm |
SM | Secure Messaging |
S/MIME | Secure Multi-Purpose Internet Mail Extensions |
SOF | Strength of Function |
SSCD | Secure Signature Creation Device |
SSL | Secure Sockets Layer |
SSM | Secured Signature Module |
SSO | Single Sign-On |
Sub CA | Subordinate CA |
SUD | Secure User Device |
SVD | Signature Verification Device |
TCPA | Trusted Computing Platform Alliance |
TOE | Target of Evaluation |
TTP | Trusted Third Party |
TSA | Time Stamping Authority |
TSP | Time Stamp Protocol |
TSS | Time Stamping Service |
TWS | Trustworthy Systems |
USB | Universal Serial Bus |
UTC | Coordinated Universal Time |
VIR | Regulation Information Security Government Service |
VPN | Virtual Private Network |
WAP | Wireless Application Protocol |
WBP | Personal Data Protection Act |
WID | Compulsory Identification Act |
WIPIWYS | What Is Presented Is What You See |
WYSIWYS | What You See Is What You Sign |
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:
- CA certificate and key life-cycle events also includes
- the Terms and Conditions accepted by the subscriber, and if it is a separate person, the subject as well, and
- 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), andszOID_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
- SHALL contain
- 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
- SHALL contain
- 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
- SHALL contain
- 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), andszOID_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
- SHALL contain
- with the Authenticity profile
- 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), andszOID_KP_DOCUMENT_SIGNING
(OID: 1.3.6.1.4.1.311.10.3.12), and
- SHALL contain
- 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), andid-kp-documentSigning
(OID: 1.3.6.1.5.5.7.3.36), and
- SHALL contain
- with the confidentiality profile
- SHALL contain
szOID_EFS_CRYPTO
(OID: 1.3.6.1.4.1.311.10.3.4), and
- SHALL contain
- with the Authenticity profile
- 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
- SHALL contain
- with any profile
- 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), andid-kp-clientAuth
(OID: 1.3.6.1.5.5.7.3.2).
- SHALL contain
- with any profile:
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’ssubjectAltName
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’ssubjectAltName
extension.
- a Fully-Qualified Domain Name (FQDN) which SHALL be one of the values contained in the
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:
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:
- The value of the serial number MUST NOT be 0 (zero);
- The value of the serial number MUST NOT be negative;
- The value of the serial number MUST be unique within the population of end-user certificates issued under an issuing TSP CA;
- The serial number MUST have a minimum length of 96 bits (12 octets);
- The value of the serial number MUST contain at least 64 bits of unpredictable random data;
- Said random data MUST be generated by a Cryptographically Secure Pseudorandom Number Generator (CSPRNG);
- 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:
- The value of the serial number MUST NOT be 0 (zero)
- The value of the serial number MUST NOT be negative
- The value of the serial number MUST be unique within the population of end-user certificates issued under an issuing TSP CA.
- The serial number MUST have a minimum length of 96 bits (12 octets)
- The value of the serial number MUST contain at least 64 bits of unpredictable random data
- Said random data SHOULD be generated by a Cryptographically Secure Pseudorandom Number Generator (CSPRNG).
- 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 valueid-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 thevalue
field related to thetype-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 thevalue
field related to thetype-id
field with value IA5String- SHALL be encoded in ISO 646 (IA5), and
- SHALL use syntax
<Assigner-OID>-<Subject-string>
.
- In the
otherName
attribute thevalue
field related to thetype-id
field with value Permanent Identifier SHALL consist out of both anidentifierValue
and anassigner
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
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
- 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
- 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:
- independence from the subject of the audit, and
- the ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme, and
- 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
- 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:
- 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 - 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 - 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:
- 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 - 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 - 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:
- 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 - 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:
- ETSI EN 319 411-1 with policy
NCP
(ETSI CP OID 0.4.0.2042.1.1), - ETSI TS 119 411-6 with policy
NCP
(ETSI CP OID 0.4.0.2042.1.1), and - 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:
- ETSI EN 319 411-1 with policies
NCP
(ETSI CP OID 0.4.0.2042.1.1) andOVCP
(ETSI CP OID 0.4.0.2042.1.7), and - 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:
- the audit report states that the TSP meets the eIDAS (910/2014) regulation requirements, and
- 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:
- for “a qualified certificate specified in article 1.1, division ss Telecommunications Act”: “a confidentiality certificate from the PKIoverheid Autonomous Devices domain” is read;
- for “signatory”: “certificate holder” is read;
- for “creation of electronic signatures”: “creation of encrypted data” is read;
- 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
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set to 1 (X.509v2 CRL profile). | INTEGER |
Describes the version of the CRL profile, the value 1 stands for X.509 version 2. | |
signature |
V | MUST be set to the algorithm, as stipulated by the PA. | RFC 5280 | OBJECT IDENTIFIER |
MUST be the same as the field signatureAlgorithm . For certificates under the G3 root certificate, only sha-256WithRSAEncryption is allowed. |
issuer |
V | MUST contain a Distinguished Name (DN). The field has attributes as described in the following rows. | PKIo, RFC 5280 | Attributes other than those mentioned below MUST NOT be used. The attributes that are used MUST be the same as the corresponding attributes in the subject field of the TSP certificate (for validation). |
|
issuer:countryName |
V | See requirement 7.1-pkio174 | ISO 3166, X.520 | PrintableString |
|
issuer:stateOrProvinceName |
N | Is not used. | PKIo | UTF8String |
|
issuer:organizationName |
V | See requirement 7.1-pkio174 | ETSI TS 102280: 5.2.4 | UTF8String |
|
issuer:organizationIdentifier |
V/N | The organizationIdentifier filed contains an identification of the issuing CA. This field MUST be included in CRLs when the field subject:organizationIdentifier is part of the TSP certificate used to sign the CRL and MUST not be included in CRLs when this field is not part of the TSP certificate in question. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identificatiestring is specified in paragraph 5.1.4 of ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - 2 character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and - identifier (according to country and identity type reference). Permissable values for this field are the OIN or the KVK number of the TSP. The information MUST be the same as the subject:organizationIdentifier incorporated in the TSP CA certificate. |
issuer:organizationalUnitName |
O | See requirement 7.1-pkio174 | ETSI TS 102280: 5.2.4 | UTF8String |
|
issuer:localityName |
N | Is not used. | PKIo | UTF8String |
|
issuer:serialNumber |
O | See requirement 7.1-pkio174 | RFC 3739 | PrintableString |
|
issuer:commonName |
V | See requirement 7.1-pkio174 | PKIo, RFC 5280 | UTF8String |
The commonName attribute MUST NOT be necessary to identify the issuing authority (not part of the Distinguished Name, requirement from RFC 3739). |
thisUpdate |
V | MUST indicate the date and time on which the CRL is amended. | RFC 5280 | UTCTime |
MUST include the issuance date of the CRL in accordance with the applicable policy set out in the CPS. |
nextUpdate |
V | MUST indicate the date and time of the next version of the CRL (when it can be expected). |
PKIo, RFC 5280 | UTCTime |
This is the latest date on which an update can be expected, however an earlier update is possible. MUST be completed in accordance with the applicable policy set out in the CPS. |
revokedCertificates |
V | MUST include the date and time of revocation and serialNumber of the revoked certificates. |
RFC 5280 | SerialNumber , UTCTime |
If there are no revoked certificates, the revoked certificates list MUST NOT be present. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityKeyIdentifier |
O | No | This attribute is interesting if a TSP has more signature certificates with which a CRL could be signed (using this attribute, it can then be ascertained which public key has to be used to verify the signature of the CRL). | RFC 5280 | KeyIdentifier |
The value MUST include the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
issuerAltName |
A | No | This attribute allows alternative names to be used for the TSP (as issuer of the CRL) (the use is advised against). |
RFC 5280 | The DNS name, IP address and URI could potentially be entered into this field. The use of an rfc822 name (e-mail address) is NOT allowed. |
|
cRLNumber |
V | No | This attribute MUST contain an incremental number that provides support when determining the order of CRLs (the TSP provides the numbering in the CRL). | RFC 5280 | INTEGER |
|
deltaCRLIndicator |
O | Yes | If ‘delta CRLs’ are used, a value for this attribute MUST be entered. | RFC 5280 | BaseCRLNumber |
Contains the number of the base CRL of which the delta CRL is an extension. |
issuingDistributionPoint |
O | Yes | If this extension is used, this attribute identifies the CRL distribution point. It can also contain additional information (such as a limited set of reason codes why the certificate has been revoked). | RFC 5280 | If used, this field MUST fulfil the specifications in RFC 5280 | |
freshestCRL |
O | No | This attribute is also known by the name ‘Delta CRL Distribution Point’. If used it MUST contain the URI of a Delta CRL distribution point. This is never present in a Delta CRL. | RFC 5280 | This field is used in complete CRLs and indicates where delta CRL information can be found that will update the complete CRL. | |
authorityInfoAccess |
O | No | Optional reference to the certificate of the CRL issuer. | RFC 5280 | id-ad-caIssuers (URI) |
MUST conform to Section 5.2.7 of RFC 5280. |
cRLReason |
O | No | The cRLReason MUST indicate the most appropriate reason for revocation of the certificate, as defined in the CPS of the TSP. The field MUST NOT contain the certificateHold value. |
RFC 5280 | reasonCode |
Explains the reason for revocation. |
holdInstructionCode |
N | No | Is not used. | RFC 5280 | OBJECT IDENTIFIER |
PKIoverheid does not use the ‘On hold’ status. |
invalidityDate |
O | No | This attribute can be used to indicate a date and time on which the certificate has become compromised if it differs from the date and time on which the TSP processed the revocation. | RFC 5280 | GeneralizedTime |
|
certificateIssuer |
A | Yes | If an indirect CRL is used, this attribute MAY be used to identify the original issuer of the certificate. |
RFC 5280 | GeneralNames |
Profile for certificates under the G3 2019 Autonomous Devices Domain
Basic attributes
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set at 2 (X.509v3). | RFC 5280 | INTEGER |
Describes the version of the certificate, the value 2 stands for X.509 version 3. |
serialNumber |
V | A serial number that MUST uniquely identify the certificate within the publishing CA domain. | RFC 5280 | INTEGER |
All end user certificates have to contain at least 8 bytes of unpredictable random data in the certificates serial number (serialNumber ). |
signature |
V | MUST be created on the algorithm, as stipulated by the PA. | RFC 5280, ETSI TS 102176 | OBJECT IDENTIFIER |
MUST be the same as the field signatureAlgorithm . For certificates under the G3 root certificate, only sha-256WithRSAEncryption is allowed. |
issuer |
V | MUST contain a Distinguished Name (DN). The field has the attributes listed below: | PKIo, RFC 3739, ETSI TS 102280 | Attributes other than those mentioned below MUST NOT be used. | |
issuer:countryName |
V | See requirement 7.1-pkio174 | ETSI TS 101862, X520, ISO 3166 | PrintableString |
|
issuer:organizationName |
V | See requirement 7.1-pkio174 | ETSI TS 102280 | UTF8String |
|
issuer:organizationalUnitName |
O | See requirement 7.1-pkio174 | ETSI TS 102280 | UTF8String |
|
issuer:serialNumber |
O | See requirement 7.1-pkio174 | RFC 3739 | PrintableString |
|
issuer:commonName |
V | MUST include the name of the CA in accordance with the accepted document or basic registry, MAY include the Domain label and/or the types of certificates that are supported | PKIo, RFC 5280, RFC 3739 | UTF8String |
The commonName attribute MUST NOT be necessary to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739) |
issuer:organizationIdentifier |
V/N | Contains an identification of the issuing TSP. This field MUST be present when the subject:organizationIdentifier is present in the TSP issuing certificate and MUST NOT be present when the subject:organizationIdentifier is NOT present in the TSP issuing certificate. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identification string is specified in paragraph 5.1.4 van ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - 2 character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and - identifier (according to country and identity type reference). |
validity |
V | MUST define the period of validity (validity) of the certificate. | RFC 5280 | UTCTime |
MUST include the start and end date for validity of the certificate in accordance with the applicable policy laid down in the CPS. |
subject |
V | The attributes that are used to describe the subject (device) MUST mention the subject in a unique way and include information about the subscriber organization. The field has the following attributes: | PKIo, RFC 3739, ETSI TS 102 280 | MUST contain a Distinguished Name (DN). Attributes other than those mentioned below MUST NOT be used. | |
subject:countryName |
V | Fixed value: C=NL, conform ISO 3166. | RFC 3739, X520, ISO 3166, PKIo | PrintableString |
Country name specifies that the certificate is issued within the context of PKIoverheid. |
subject:commonName |
V | See requirement 7.1-pkio205. | RFC 3739, ETSI TS 102 280, PKIo | UTF8String |
See requirement 7.1-pkio205. |
subject:organizationName |
V | The full name of the subscribers organization in accordance with the accepted document or Basic Registry. | PKIo | UTF8String |
The subscriber organization is the organization with which the TSP has entered into an agreement for the linkage/award of certificates to devices within the framework of standards drawn up by the party responsible for establishing the framework. |
subject:stateOrProvinceName |
A | The use is advised against. If present, this field MUST contain the province in which the subscriber is established in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the province MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:localityName |
A | The use is advised against. If present, this field MUST contain the location of the subscriber in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the location MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:serialNumber |
O | The TSP is responsible for safeguarding the uniqueness of the subject (device). The subject:serialNumber MUST be used to identify the subject uniquely. |
RFC 3739, X 520, PKIo | PrintableString |
The number is determined by the TSP and/or the government. The number can differ for each domain and can be used for several applications. In addition to the definition in RFC 3739, the number MAY be added to, in order to identify as well as the subject, for example, the SUD. |
subject:title |
O | SHALL be an attribute describing the authorization of the (autonomous) device according to a framework of standards, as verified by means which SHALL be described in the TSP CPS. | ETSI TS 102 280, RFC 3739, RFC 5280 | ||
subjectPublicKeyInfo |
V | Contains, among other things, the public key. | ETSI TS 102 280, RFC 3279 | Contains the public key, identifies the algorithm with which the key can be used. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityKeyIdentifier |
V | No | The algorithm to generate the authorityKey MUST be created on an algorithm determined by the PA. |
ETSI TS 102 280, RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
subjectKeyIdentifier |
V | No | The algorithm to generate the subjectKey MUST be created on an algorithm determined by the PA. |
RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the subjectKey (public key of the certificate holder). |
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate. In the PKI for the government, for each certificate type various bits are incorporated in the keyUsage extension. The digitalSignature bit MUST be included in authenticity certificates. Another keyUsage MAY NOT be combined with this. In confidentiality certificates, the keyEncipherment and dataEncipherment bits MUST be included. Another keyUsage MAY NOT be combined with this. In combination certificates the digitalSignature , keyEncipherment and keyAgreement bits MUST be incorporated and marked as critical. Another keyUsage MAY NOT be combined with this. |
RFC 3739, RFC 5280, ETSI TS 102 280 | BIT STRING |
|
certificatePolicies |
V | No | MUST contain the OID of the Certificate Policy (CP) and the URI of the Certification Practice Statement (CPS), and MAY contain a user notice. The TSP SHOULD use UTF8String in the userNotice field, but MAY use IA5String . ALL certificates issued with their private key residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP+ OID [0.4.0.2042.1.2]; those issued with their private key NOT residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP OID [0.4.0.2042.1.1]. |
RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
An overview of all Certificate Policy OIDs can be found in the document “PKIoverheid registered OIDs”. For the Autonomous Devices domain the OIDs are: - Authenticity: 2.16.528.1.1003.1.2.6.1 - Confidentiality: 2.16.528.1.1003.1.2.6.2 - Combination: 2.16.528.1.1003.1.2.5.5 Reference to the paragraph numbers of the PoR in the user notice is advised against because the persistency of this cannot be guaranteed (unlike the OID number of the CP). |
subjectAltName |
V | No | Contains one or more alternative names/identification numbers of the certificate holder | RFC 5280, PKIo, ETSI TS 102 280 | Attributes other than those mentioned below MUST NOT be used. | |
subjectAltName:otherName |
O | N/A | See requirement 7.1-pkio202. | PKIo | See description | See description. |
subjectAltName:rfc822Name |
A | N/A | MAY be used for the services e-mail address, for applications that need the e-mail address in order to be able to function properly. | RFC 5280 | IA5String |
For PKIoverheid certificates, the use of e-mail addresses is advised against, because e-mail addresses of certificate holders often change and are susceptible to spam. |
basicConstraints |
O | Yes | This field SHALL have its cA sub-field set to its DEFAULT value (FALSE) resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included. |
RFC 5280 | ITU-T Recommendation X.690 (07/2002) on ASN.1 encoding rules states in Section 5.8: “The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value”. Stating in the description that “encoded certificates do NOT include the cA sub-field” therefore is redundant. However, in the past some TSPs employed CA-issuing software which did not do proper ASN.1 encoding resulting in a wrongfully included cA sub-field in encoded certificates. This encoding error resulted in some PKIX software rejecting these certificates. This redundant information therefore has to be regarded as a cautionary hint for TSPs to check their actual certificate encoding for these errors. Chances of this encoding bug still existing in ASN.1 encoding software are however slim since the last mention of such a bug on BugZilla is from 2016. |
|
cRLDistributionPoints |
V | No | MUST include the URI of a CRL distribution point. | RFC 5280, ETSI TS 102 280 | The reference MUST be accessible through the HTTP or LDAP protocol. The attribute reason MUST NOT be used, reference MUST be made to 1 CRL for all types of reasons for revocation. In addition to CRL, other types of certificate status information service MAY be supported. |
|
extKeyUsage |
V | Yes / No | RFC 5280 | KeyPurposeId s |
See requirement 7.1-pkio149. |
Private extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityInfoAccess accessMethod (id-ad-caIssuers ) |
O | An accessDescription item with accessMethod id-ad-caIssuers references the online location where the certificate of the TSP CA that signed the current certificate (issue) is located. |
RFC 5280 | GeneralName (URI) |
This attribute MUST include the URI of the relevant certificate file/object. If this is an HTTP-URI, the file that is referenced is preferably a DER-coded CA certificate file, that is seen by the relevant HTTP server as the type MIME “application/pkix-cert”. |
Profile for certificates under the G3 Legacy Citizen Domain
Basic attributes
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set at 2 (X.509v3). | RFC 5280 | INTEGER |
Describes the version of the certificate, the value 2 stands for X.509 version 3. |
serialNumber |
V | A serial number that MUST uniquely identify the certificate within the publishing CA domain. | RFC 5280 | INTEGER |
All end user certificates have to contain at least 8 bytes of unpredictable random data in the certificates serial number (serialNumber ). |
signature |
V | MUST be created on the algorithm, as stipulated by the PA. | RFC 5280, ETSI TS 102176 | OBJECT IDENTIFIER |
MUST be the same as the field signatureAlgorithm . For certificates under the G3 root certificate, only sha-256WithRSAEncryption is allowed. |
issuer |
V | MUST contain a Distinguished Name (DN). The field has the following attributes: | PKIo, RFC 3739, ETSI TS 102280 | Attributes other than those mentioned below MUST NOT be used. | |
issuer:countryName |
V | See requirements 7.1-pkio174 | ETSI TS 101862, X520, ISO 3166 | PrintableString |
|
issuer:organizationName |
V | See requirements 7.1-pkio174 | ETSI TS 102280 | UTF8String |
|
issuer:organizationalUnitName |
O | See requirements 7.1-pkio174 | ETSI TS 102280: 5.2.4 | UTF8String |
|
issuer:serialNumber |
O | See requirements 7.1-pkio174 | RFC 3739 | PrintableString |
|
issuer:commonName |
V | See requirements 7.1-pkio174 | PKIo, RFC 3739 | UTF8String |
The commonName attribute MUST NOT be necessary in order to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739) |
issuer:organizationIdentifier |
V/N | Contains an identification of the issuing TSP. This field MUST be present when the subject:organizationIdentifier is present in the TSP issuing certificate and MUST NOT be present when the subject:organizationIdentifier is NOT present in the TSP issuing certificate. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identification string is specified in paragraph 5.1.4 van ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - 2 character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and - identifier (according to country and identity type reference). |
validity |
V | MUST define the period of validity of the certificate according to RFC 5280. | RFC 5280 | UTCTime |
MUST include the start and end date for validity of the certificate in accordance with the applicable policy laid down in the CPS. |
subject |
V | The attributes that are used to describe the subject (end user) MUST mention the subject in a unique manner. The field has the following attributes: |
PKIo, RFC 3739, ETSI TS 102 280 | MUST contain a Distinguished Name (DN). Attributes other than those mentioned below MUST NOT be used. | |
subject:countryName |
V | Complete C with two-letter country code in accordance with ISO 3166-1. If an official alpha-2 code is missing, the TSP MAY use the user-assigned code XX. | RFC 3739, X520, ISO 3166, PKIo | PrintableString |
The country code that is used in subject:countryName MUST correspond with the subscribers address in accordance with the accepted document or registry. |
subject:commonName |
V | See requirement 7.1-pkio203. | RFC 3739, ETSI TS 102 280, PKIo | UTF8String |
See requirement 7.1-pkio203. |
subject:givenName |
V/O | A correct reproduction of the element of the name laid down in the CN. Based on the Compulsory Identification Act document. | RFC 3739 | UTF8String |
This field MUST show the subjects first name(s) correctly as shown on the Compulsory Identification Act document. |
subject:stateOrProvinceName |
A | The use is advised against. If present, this field MUST contain the province of the certificate holders branch in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the province MUST correspond with the certificate holders address in accordance with the GBA. The certificate holder will have to submit recent proof of his address. |
subject:localityName |
A | The use is advised against. If present, this field MUST contain the location of the certificate holder in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the domicile MUST correspond with the certificate holders address in accordance with the GBA. The certificate holder will have to submit recent proof of his address. |
subject:serialNumber |
V | Number to be determined by the TSP. The combination of commonName , organizationName and serialNumber MUST be unique within the context of the TSP. |
RFC 3739, X 520, PKIo | PrintableString |
The serialNumber is intended to distinguish between subjects with the same commonName and the same organizationName . To avoid susceptibilities a serialNumber attribute MUST be allocated to every subject. |
subjectPublicKeyInfo |
V | Contains, among other things, the public key. | ETSI TS 102 280, RFC 3279 | Contains the public key, identifies the algorithm with which the key can be used. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityKeyIdentifier |
V | No | The algorithm to generate the authorityKey MUST be created on an algorithm determined by the PA. |
ETSI TS 102 280, RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
subjectKeyIdentifier |
V | No | The algorithm to generate the subjectKey MUST be created on an algorithm determined by the PA. |
RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the subjectKey (public key of the certificate holder). |
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate. For each certificate type various bits are incorporated in the keyUsage extension. In authenticity certificates the digitalSignature bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In confidentiality certificates, keyEncipherment and dataEncipherment bits MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In certificates for the electronic signature the nonRepudiation bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. |
RFC 3739, RFC 5280, ETSI TS 102 280 | BIT STRING |
|
certificatePolicies |
V | No | MUST contain the OID of the Certificate Policy (CP) and the URI of the Certification Practice Statement (CPS), and MAY contain a user notice. The TSP SHOULD use UTF8String in the userNotice field, but MAY use IA5String . ALL certificates issued with their private key residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP+ OID [0.4.0.2042.1.2]; those issued with their private key NOT residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP OID [0.4.0.2042.1.1]. Certificates issued as EU qualified certificates to natural persons with their private key residing in a QSCD, SHOULD contain an additional ETSI QCP-n-qscd OID [0.4.0.194112.1.2], or an additional ETSI QCP-n OID of [0.4.0.194112.1.0] when their private key does not reside on a QSCD. |
RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
An overview of all Certificate Policy OIDs can be found in the document “PKIoverheid registered OIDs”. For the Citizen domain the OIDs are: - Authenticity: 2.16.528.1.1003.1.2.3.1 - Non-repudiation (eSignatures): 2.16.528.1.1003.1.2.3.2 - Confidentiality: 2.16.528.1.1003.1.2.3.3 - If S/MIME capable: 2.23.140.1.5.4.1 Reference to the paragraph numbers of the PoR in the user notice is advised against because the persistency of this cannot be guaranteed (unlike the OID number of the CP). |
subjectAltName |
V | No | Contains one or more alternative names/identification numbers of the certificate holder | RFC 5280, PKIo, ETSI TS 102 280 | Attributes other than those mentioned below MUST NOT be used. | |
subjectAltName:otherName |
O | N/A | See requirement 7.1-pkio202. | PKIo | See description | See description. |
subjectAltName:rfc822Name |
A | MAY be used for the certificate holders e-mail address, for applications that need the e-mail address to be able to function properly. | RFC 5280 | IA5String |
For PKIoverheid certificates, the use of e-mail addresses is advised against, because e-mail addresses of certificate holders often change and are susceptible to spam. If the e-mail address is included in the certificate, the TSP MUST: - have the subscriber sign for approval, and; - check whether the email address belongs to the subscriber and that the subscriber has access to the email address (for example by performing a challenge response). |
|
basicConstraints |
O | Yes | This field SHALL have its cA sub-field set to its DEFAULT value (FALSE) resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included. |
RFC 5280 | ITU-T Recommendation X.690 (07/2002) on ASN.1 encoding rules states in Section 5.8: “The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value”. Stating in the description that “encoded certificates do NOT include the cA sub-field” therefore is redundant. However, in the past some TSPs employed CA-issuing software which did not do proper ASN.1 encoding resulting in a wrongfully included cA sub-field in encoded certificates. This encoding error resulted in some PKIX software rejecting these certificates. This redundant information therefore has to be regarded as a cautionary hint for TSPs to check their actual certificate encoding for these errors. Chances of this encoding bug still existing in ASN.1 encoding software are however slim since the last mention of such a bug on BugZilla is from 2016. |
|
cRLDistributionPoints |
V | No | MUST include the URI of a CRL distribution point. | RFC 5280, ETSI TS 102 280 | The reference MUST be accessible through the HTTP or LDAP protocol. The attribute reason MUST NOT be used, reference MUST be made to 1 CRL for all types of reasons for revocation. In addition to CRL, other types of certificate status information service MAY be supported. |
|
extKeyUsage |
V | No | RFC 5280 | See requirement 7.1-pkio149. |
Private extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityInfoAccess |
O | No | This attribute MUST include the URI of an OCSP responder if Online Certificate Status Protocol (OCSP) plays a role. | This field can optionally be used to reference other additional information about the TSP. | ||
QcStatement |
V/N | No | Certificates for the electronic signature MUST indicate that they are issued as qualified certificates complying with annex I of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qcs-QcCompliance statement in this extension. Certificates for the electronic signature MUST indicate that they are issued as type of certificate complying with annex I of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qct-esign statement in this extension. Certificates for the electronic signature MUST indicate that the private key that is part of the public key in the certificate is saved on a qualified signature creation device (QSCD) complying with annex II of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qcs-QcSSCD statement in this extension. Certificates for the electronic signature MUST contain a reference to the location of the PKI Disclosure Statement (PDS). This URL must present in the id-etsi-qcs-QcPDS statement in this extension.
The certificates for authenticity and the certificates for confidentiality MUST NOT use this extention. |
RFC 3739, ETSI TS 102 280, ETSI TS 101 862 | OBJECT IDENTIFIER |
The aforementioned QcStatement identifiers relate to the following OIDs: - id-etsi-qcs-QcCompliance { id-etsi-qcs 1 } 0.4.0.1862.1.1 - id-etsi-qct-esign { id-etsi-qcs-QcType 1 } 0.4.0.1862.1.6.1 - id-etsi-qcs-QcSSCD { id-etsi-qcs 4 } 0.4.0.1862.1.4 - id-etsi-qcs-QcPDS { id-etsi-qcs 5 } 0.4.0.1862.1.5 |
Profile for certificates under the G3 Legacy Organization Person Domain
Basic attributes
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set at 2 (X.509v3). | RFC 5280 | INTEGER |
Describes the version of the certificate, the value 2 stands for X.509 version 3. |
serialNumber |
V | A serial number that MUST uniquely identify the certificate within the publishing CA domain. | RFC 5280 | INTEGER |
All end user certificates have to contain at least 8 bytes of unpredictable random data in the certificate’s serial number (serialNumber ). |
signature |
V | MUST be set on the algorithm, as stipulated by the PA. | RFC 5280, ETSI TS 102176 | OBJECT IDENTIFIER |
MUST be the same as the field signatureAlgorithm . For certificates under the G3 root certificate, only sha-256WithRSAEncryption is allowed. |
issuer |
V | MUST contain a Distinguished Name (DN). The field has the following attributes | PKIo, RFC 3739, ETSI TS 102280 | Attributes other than those mentioned below MUST NOT be used. | |
issuer:countryName |
V | See requirement 7.1-pkio174 | ETSI TS 101862, X520, ISO 3166 | PrintableString |
|
issuer:organizationName |
V | See requirement 7.1-pkio174 | ETSI TS 102280 | UTF8String |
|
issuer:organizationalUnitName |
O | See requirement 7.1-pkio174 | ETSI TS 102280: 5.2.4 | UTF8String |
|
issuer:serialNumber |
O | See requirement 7.1-pkio174 | RFC 3739 | PrintableString |
|
issuer:commonName |
V | See requirement 7.1-pkio174 | PKIo, RFC 3739 | UTF8String |
The commonName attribute MUST NOT be necessary in order to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739) |
issuer:organizationIdentifier |
V/N | Contains an identification of the issuing TSP. This field MUST be present when the subject:organizationIdentifier is present in the TSP issuing certificate and MUST NOT be present when the subject:organizationIdentifier is NOT present in the TSP issuing certificate. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identification string is specified in paragraph 5.1.4 van ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - 2 character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and - identifier (according to country and identity type reference). |
validity |
V | MUST define the period of validity of the certificate according to RFC 5280. | RFC 5280 | UTCTime |
MUST include the start and end date for validity of the certificate in accordance with the applicable policy laid down in the CPS. |
subject |
V | The attributes that are used to describe the subject (end user) MUST mention the subject in a unique manner and include information about the subscriber. The field has the following attributes |
PKIo, RFC 3739, ETSI TS 102 280 | MUST contain a Distinguished Name (DN). Attributes other than those mentioned below MUST NOT be used. | |
subject:countryName |
V | Complete C with two-letter country code in accordance with ISO 3166-1. If an official alpha-2 code is missing, the TSP MAY use the user-assigned code XX. | RFC 3739, X520, ISO 3166, PKIo | PrintableString |
The country code that is used in subject:countryName MUST correspond with the subscriber’s address in accordance with the accepted document or registry. |
subject:commonName |
V | See requirement 7.1-pkio203. | RFC 3739, ETSI TS 102 280, PKIo | UTF8String |
See requirement 7.1-pkio203. |
subject:surname |
V | A correct reproduction of the element of the name laid down in the CN. Based on the Compulsory Identification Act document. | RFC 3739 | UTF8String |
This field MUST show the subject’s surname including surname prefixes correctly, as shown on the Compulsory Identification Act document. |
subject:givenName |
V/O | A correct reproduction of the element of the name laid down in the CN. Based on the Compulsory Identification Act document. | RFC 3739 | UTF8String |
This field MUST show the subject’s surname including surname prefixes correctly, as shown on the Compulsory Identification Act document. |
subject:organizationName |
V | Full name of the subscriber in accordance with the accepted document or Basic Registry | PKIo | UTF8String |
The subscriber is the entity with which the TSP has entered into an agreement and on behalf of which or pursuant to which the certificate holder acts when using the certificate. In occupational-linked certificates this is equal to the common name of the certificate holder. |
subject:organizationIdentifier |
N/V | This field SHALL be present ONLY when a certificate is S/MIME-capable. The value of the subject:organizationIdentifier field SHALL contain EITHER: - an identifier conforming to the semantics for legal person identifiers set forth in Section 5.1.4 of ETSI standard EN 319 412-1, or - an OIN/HRN number. |
SBRG | UTF8String |
TSPs wanting to use a register for legal person identifiers which could qualify as a “national scheme” as described in ETSI standard EN 319 412-1 Section 5.1.4 can apply at Logius for a two-character encoding identifying the relevant source. These encodings will be added to the PKIo CPS. OIN/HRN identifiers adhering to the “national scheme” clause in Section 5.1.4 of ETSI standard EN 319 412-1 are preferred from a standards perspective. This will however mean many governmental systems have to be altered, making this not a likely scenario for the forseeable future. |
subject:stateOrProvinceName |
A | The use is advised against. If present, this field MUST contain the province in which the subscriber is established in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the province MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:localityName |
A | The use is advised against. If present, this field MUST contain the location of the subscriber in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the location MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:serialNumber |
V | Number to be determined by the TSP. The combination of commonName , organizationName and serialNumber MUST be unique within the context of the TSP. |
RFC 3739, X 520, PKIo | PrintableString |
The serialNumber is intended to distinguish between subjects with the same commonName and the same organizationName . To avoid susceptibilities a serialNumber attribute MUST be allocated to every subject. |
subject:title |
V/N | MUST contain value from limitative list of professions in PoR requirement 3.2.5-pkio160. | ETSI TS 102 280, RFC 3739, RFC 5280 | This field SHALL only be used in certificates of the ‘professional certificate’ type. | |
subjectPublicKeyInfo |
V | Contains, among other things, the public key. | ETSI TS 102 280, RFC 3279 | Contains the public key, identifies the algorithm with which the key can be used. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityKeyIdentifier |
V | No | The algorithm to generate the authorityKey MUST be created on an algorithm determined by the PA. |
ETSI TS 102 280, RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
subjectKeyIdentifier |
V | No | The algorithm to generate the subjectKey MUST be created on an algorithm determined by the PA. |
RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the subjectKey (public key of the certificate holder). |
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate. For each certificate type various bits are incorporated in the keyUsage extension. In authenticity certificates the digitalSignature bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In confidentiality certificates, keyEncipherment and dataEncipherment bits MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In certificates for the electronic signature the nonRepudiation bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. |
RFC 3739, RFC 5280, ETSI TS 102 280 | BIT STRING |
|
certificatePolicies |
V | No | MUST contain the OID of the Certificate Policy (CP) and the URI of the Certification Practice Statement (CPS), and MAY contain a user notice. The TSP SHOULD use UTF8String in the userNotice field, but MAY use IA5String . ALL certificates issued with their private key residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP+ OID [0.4.0.2042.1.2]; those issued with their private key NOT residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP OID [0.4.0.2042.1.1]. Certificates issued as EU qualified certificates to natural persons with their private key residing in a QSCD, SHOULD contain an additional ETSI QCP-n-qscd OID [0.4.0.194112.1.2], or an additional ETSI QCP-n OID of [0.4.0.194112.1.0] when their private key does not reside on a QSCD. |
RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
An overview of all Certificate Policy OIDs can be found in the document “PKIoverheid registered OIDs”. For the Organization Person domain the OIDs are: - Authenticity: 2.16.528.1.1003.1.2.5.1 - Non-repudiation: 2.16.528.1.1003.1.2.5.2 - Confidentiality: 2.16.528.1.1003.1.2.5.3 - If S/MIME capable: 2.23.140.1.5.3.1 Reference to the paragraph numbers of the PoR in the user notice is advised against because the persistency of this cannot be guaranteed (unlike the OID number of the CP). |
subjectAltName |
V | No | Contains one or more alternative names/identification numbers of the certificate holder | RFC 5280, PKIo, ETSI TS 102 280 | Attributes other than those mentioned below MUST NOT be used. | |
subjectAltName:otherName |
O | N/A | See requirement 7.1-pkio202. | PKIo | See description | See description. |
subjectAltName:rfc822Name |
A | MAY be used for the certificate holder’s e-mail address, for applications that need the e-mail address to be able to function properly. | RFC 5280 | IA5String |
For PKIoverheid certificates in the Government/Companies and Organization domains, the use of e-mail addresses is advised again, because e-mail addresses of certificate holders often change and furthermore are privacy sensitive (spam). If the e-mail address is included in the certificate, the TSP MUST: - have the subscriber sign his/her approval for these and; - check that the e-mail address belongs to the subscriber’s domain, or; - check that the e-mail address belongs to the subscriber (e.g. the professional) and that this person has access to the e-mail address (for example by performing a challenge response). |
|
basicConstraints |
O | Yes | This field SHALL have its cA sub-field set to its DEFAULT value (FALSE ) resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included. |
RFC 5280 | ITU-T Recommendation X.690 (07/2002) on ASN.1 encoding rules states in Section 5.8: “The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value”. Stating in the description that “encoded certificates do NOT include the cA sub-field” therefore is redundant. However, in the past some TSPs employed CA-issuing software which did not do proper ASN.1 encoding resulting in a wrongfully included cA sub-field in encoded certificates. This encoding error resulted in some PKIX software rejecting these certificates. This redundant information therefore has to be regarded as a cautionary hint for TSPs to check their actual certificate encoding for these errors. Chances of this encoding bug still existing in ASN.1 encoding software are however slim since the last mention of such a bug on BugZilla is from 2016. |
|
cRLDistributionPoints |
V | No | MUST include the URI of a CRL distribution point. | RFC 5280, ETSI TS 102 280 | The reference MUST be accessible through the HTTP or LDAP protocol. The attribute reason MUST NOT be used, reference MUST be made to 1 CRL for all types of reasons for revocation. In addition to CRL, other types of certificate status information service MAY be supported. |
|
extKeyUsage |
V | No | RFC 5280 | KeyPurposeId |
See requirement 7.1-pkio149. |
Private extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityInfoAccess |
O | No | This attribute MUST include the URI of an OCSP responder if Online Certificate Status Protocol (OCSP) plays a role. | This field can optionally be used to reference other additional information about the TSP. | ||
QcStatement |
V/N | No | Certificates for the electronic signature MUST indicate that they are issued as qualified certificates complying with annex I of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qcs-QcCompliance statement in this extension. Certificates for the electronic signature MUST indicate that they are issued as type of certificate complying with annex I of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qct-esign statement in this extension. Certificates for the electronic signature MUST indicate that the private key that is part of the public key in the certificate is saved on a qualified signature creation device (QSCD) complying with annex II of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qcs-QcSSCD statement in this extension. Certificates for the electronic signature MUST contain a reference to the location of the PKI Disclosure Statement (PDS). This URL must present in the id-etsi-qcs-QcPDS statement in
this extension. The certificates for authenticity and the certificates for confidentiality MUST NOT use this extension. |
RFC 3739, ETSI TS 102 280, ETSI TS 101 862 | OBJECT IDENTIFIER |
The aforementioned QcStatement identifiers relate to the following OIDs: - id-etsi-qcs-QcCompliance { id-etsi-qcs 1 } 0.4.0.1862.1.1 - id-etsi-qct-esign { id-etsi-qcs-QcType 1 } 0.4.0.1862.1.6.1 - id-etsi-qcs-QcSSCD { id-etsi-qcs 4 } 0.4.0.1862.1.4 - id-etsi-qcs-QcPDS { id-etsi-qcs 5 } 0.4.0.1862.1.5 |
Profile for certificates under the G3 Legacy Organization Services Domain
Basic attributes
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set at 2 (X.509v3). | RFC 5280 | INTEGER |
Describes the version of the certificate, the value 2 stands for X.509 version 3. |
serialNumber |
V | A serial number that MUST uniquely identify the certificate within the publishing CA domain. | RFC 5280 | INTEGER |
All end user certificates have to contain at least 8 bytes of unpredictable random data in the certificate’s serial number (serialNumber ). |
signature |
V | MUST be created on the algorithm, as stipulated by the PA. | RFC 5280, ETSI TS 102176 | OBJECT IDENTIFIER |
MUST be the same as the field signatureAlgorithm . |
issuer |
V | MUST contain a Distinguished Name (DN). The field has the following attributes: | PKIo, RFC 3739, ETSI TS 102280 | Attributes other than those mentioned below MUST NOT be used. | |
issuer:countryName |
V | See requirement 7.1-pkio174. | ETSI TS 101862, X520, ISO 3166 | PrintableString |
|
issuer:organizationName |
V | See requirement 7.1-pkio174. | ETSI TS 102280 | UTF8String |
|
issuer:organizationalUnitName |
O | See requirement 7.1-pkio174. | ETSI TS 102280 | UTF8String |
|
issuer:serialNumber |
O | See requirement 7.1-pkio174. | RFC 3739 | PrintableString |
|
issuer:commonName |
V | See requirement 7.1-pkio174. | PKIo, RFC 3739 | UTF8String |
The commonName attribute MUST NOT be needed to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739) |
issuer:organizationIdentifier |
V/N | Contains an identification of the issuing TSP. This field MUST be present when the subject:organizationIdentifier is present in the TSP issuing certificate and MUST NOT be present when the subject:organizationIdentifier is NOT present in the TSP issuing certificate. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identification string is specified in paragraph 5.1.4 van ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - 2 character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and - identifier (according to country and identity type reference). |
validity |
V | MUST define the period of validity of the certificate according to RFC 5280. | RFC 5280 | UTCTime |
MUST include the start and end date for validity of the certificate in accordance with the applicable policy laid down in the CPS. |
subject |
V | The attributes that are used to describe the subject (service) MUST mention the subject in a unique way and include information about the subscriber organization. The field has the following attributes: | PKIo, RFC 3739, ETSI TS 102 280 | MUST contain a Distinguished Name (DN). Attributes other than those mentioned below MUST NOT be used. | |
subject:countryName |
V | Complete C with two-letter country code in accordance with ISO 3166-1. If an official alpha-2 code is missing, the TSP MAY use the user-assigned code XX. | RFC 3739, X520, ISO 3166, PKIo | PrintableString |
The country code that is used in subject:countryName MUST correspond with the subscriber’s address in accordance with the accepted document or registry. |
subject:commonName |
V | See requirement 7.1-pkio204. | RFC 3739, ETSI TS 102 280, PKIo | UTF8String |
See requirement 7.1-pkio204. |
subject:organizationName |
V | The full name of the subscriber’s organization in accordance with the accepted document or Basic Registry. | PKIo | UTF8String |
The subscriber organization is the organization with which the TSP has entered into an agreement and on behalf of which the certificate holder (service) communicates or acts. |
subject:organizationIdentifier |
V | The value of the subject:organizationIdentifier field SHALL contain EITHER: - an identifier conforming to the semantics for legal person identifiers set forth in Section 5.1.4 of ETSI standard EN 319 412-1, or - an OIN/HRN number. |
ETSI EN 319 412-1 | UTF8String |
TSPs wanting to use a register for legal person identifiers which could qualify as a “national scheme” as described in ETSI standard EN 319 412-1 Section 5.1.4 can apply at Logius for a two-character encoding identifying the relevant source. These encodings will be added to the PKIo CPS. OIN/HRN identifiers adhering to the “national scheme” clause in Section 5.1.4 of ETSI standard EN 319 412-1 are preferred from a standards perspective. This will however mean many governmental systems have to be altered, making this not a likely scenario for the forseeable future. |
subject:organizationalUnitName |
A | Usage of the subject:organizationalUnitName field is discouraged. When used the value of the subject:organizationalUnitName field SHALL be an identifier of an organizational entity, the validation of which SHALL be described in the CPS of the TSP. This value SHALL NOT resemble functional roles or titles. |
PKIo | Usage of the subject:organizationalUnitName field is discouraged because it is inherently impossible to verify through independent sources with the exception of certain sub-OINs in the OIN register. Note: The dentifier of an organizational entity can be in any form, i.e. name, number, or a combination of both. |
|
subject:stateOrProvinceName |
A | The use is advised against. If present, this field MUST contain the province in which the subscriber is established in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the province MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:localityName |
A | The use is advised against. If present, this field MUST contain the location of the subscriber in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the location MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:serialNumber |
O | The TSP is responsible for safeguarding the uniqueness of the subject (service). The subject:serialNumber MUST be used to identify the subject uniquely. The use of 20 positions is only allowed for OIN and HRN after additional arrangements with Logius. |
RFC 3739, X 520, PKIo | PrintableString |
The number is determined by the TSP and/or the government. The number can differ for each domain and can be used for several applications. |
subjectPublicKeyInfo |
V | Contains, among other things, the public key. | ETSI TS 102 280, RFC 3279 | Contains the public key, identifies the algorithm with which the key can be used. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityKeyIdentifier |
V | No | The algorithm to generate the authorityKey MUST be created on an algorithm determined by the PA. |
ETSI TS 102 280, RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
subjectKeyIdentifier |
V | No | The algorithm to generate the subjectKey MUST be created on an algorithm determined by the PA. |
RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the subjectKey (public key of the certificate holder). |
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate. For each certificate type various bits are incorporated in the keyUsage extension. In authenticity certificates the digitalSignature bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In confidentiality certificates, keyEncipherment and dataEncipherment bits MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In certificates for the electronic seal the nonRepudiation bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. |
RFC 3739, RFC 5280, ETSI TS 102 280 | BIT STRING |
|
certificatePolicies |
V | No | MUST contain the OID of the Certificate Policy (CP) and the URI of the Certification Practice Statement (CPS), and MAY contain a user notice. The TSP SHOULD use UTF8String in the userNotice field, but MAY use IA5String . ALL certificates issued with their private key residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP+ OID [0.4.0.2042.1.2]; those issued with their private key NOT residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP OID [0.4.0.2042.1.1]. Certificates issued as EU qualified certificates to legal persons with their private key residing in a QSCD, SHOULD contain an additional ETSI QCP-l-qscd OID [0.4.0.194112.1.3], or an additional ETSI QCP-l OID of [0.4.0.194112.1.1] when their private key does not reside on a QSCD |
RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
An overview of all Certificate Policy OIDs can be found in the document “PKIoverheid registered OIDs”. For the Organization Services domain the OIDs are: - Authenticity: 2.16.528.1.1003.1.2.5.4 - Non-repudiation (eSeal): 2.16.528.1.1003.1.2.5.7 - Confidentiality: 2.16.528.1.1003.1.2.5.5 - If S/MIME capable: 2.23.140.1.5.2.1 Reference to the paragraph numbers of the PoR in the user notice is advised against because the persistency of this cannot be guaranteed (unlike the OID number of the CP). |
subjectAltName |
O | No | Contains one or more alternative names/identification numbers of the certificate holder | RFC 5280, PKIo, ETSI TS 102 280 | Attributes other than those mentioned below MUST NOT be used. | |
subjectAltName:otherName |
O | See requirement 7.1-pkio202. | PKIo | See description | See description. | |
subjectAltName:rfc822Name |
A | MAY be used for the service’s e-mail address, for applications that need the e-mail address in order to be able to function properly. | RFC 5280 | IA5String |
For PKIoverheid certificates, the use of e-mail addresses is advised against, because e-mail addresses of certificate holders often change and are susceptible to spam. | |
basicConstraints |
O | Yes | This field SHALL have its cA sub-field set to its DEFAULT value (FALSE) resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included. |
RFC 5280 | ITU-T Recommendation X.690 (07/2002) on ASN.1 encoding rules states in Section 5.8: “The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value”. Stating in the description that “encoded certificates do NOT include the cA sub-field” therefore is redundant. However, in the past some TSPs employed CA-issuing software which did not do proper ASN.1 encoding resulting in a wrongfully included cA sub-field in encoded certificates. This encoding error resulted in some PKIX software rejecting these certificates. This redundant information therefore has to be regarded as a cautionary hint for TSPs to check their actual certificate encoding for these errors. Chances of this encoding bug still existing in ASN.1 encoding software are however slim since the last mention of such a bug on BugZilla is from 2016. |
|
cRLDistributionPoints |
V | No | MUST include the URI of a CRL distribution point. | RFC 5280, ETSI TS 102 280 | The reference MUST be accessible through the HTTP or LDAP protocol. The attribute reason MUST NOT be used, reference MUST be made to 1 CRL for all types of reasons for revocation. In addition to CRL, other types of certificate status information service MAY be supported. |
|
extKeyUsage |
V | No | RFC 5280 | KeyPurposeId s |
See requirement 7.1-pkio149. |
Private extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityInfoAccess |
O | No | This attribute MUST include the URI of an OCSP responder if Online Certificate Status Protocol (OCSP) plays a role. | This field can optionally be used to reference other additional information about the TSP. | ||
QcStatement |
V/N | No | Certificates for the electronic seals MUST indicate that they are issued as qualified certificates complying with annex III of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qcs-QcCompliance statement in this extension. Certificates for the electronic seals MUST indicate that they are issued as type of certificate complying with annex I of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qct-eseal statement in this extension. Certificates for the electronic seals MUST indicate that the private key that is part of the public key in the certificate is saved on a qualified signature creation device (QSCD) complying with annex II of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qcs-QcSSCD statement in this extension. Certificates for the electronic signature MUST contain a reference to the location of the PKI Disclosure Statement (PDS). This URL must present in the id-etsi-qcs-QcPDS statement in this
extension. |
RFC 3739, ETSI TS 102 280, ETSI TS 101 862 | OBJECT IDENTIFIER |
The aforementioned QcStatement identifiers relate to the following OIDs: - id-etsi-qcs-QcCompliance { id-etsi-qcs 1 } 0.4.0.1862.1.1 - id-etsi-qct-eseal { id-etsi-qcs-QcType 2 } 0.4.0.1862.1.6.2 - id-etsi-qcs-QcSSCD { id-etsi-qcs 4 } 0.4.0.1862.1.4 - id-etsi-qcs-QcPDS { id-etsi-qcs 5 } 0.4.0.1862.1.5 |
QcStatement-2 |
V | No | This extension munst contain an id-etsi-qcs-SemanticsId-Legal statement. This semantics identifier indicates that the organizationalIdentifier in the subject adheres to the prescribed layout. |
ETSI EN 319 412-1 | OBJECT IDENTIFIER |
Said QcStatement identifiers are the following OIDs: id-etsi-qcs-SemanticsId-Legal { id-etsi-qcs-semantics-identifiers 2 } 0.4.0.194121.1.2 |
Profile for certificates under the G3 2023 Citizen Domain
Basic attributes
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set at 2 (X.509v3). | RFC 5280 | INTEGER |
Describes the version of the certificate, the value 2 stands for X.509 version 3. |
serialNumber |
V | A serial number that MUST uniquely identify the certificate within the publishing CA domain. | RFC 5280 | INTEGER |
All end user certificates have to contain at least 8 bytes of unpredictable random data in the certificates serial number (serialNumber ). |
signature |
V | MUST be created on the algorithm, as stipulated by the PA. | RFC 5280, ETSI TS 102176 | OBJECT IDENTIFIER |
MUST be the same as the field signatureAlgorithm . For certificates under the G3 root certificate, only sha-256WithRSAEncryption is allowed. |
issuer |
V | MUST contain a Distinguished Name (DN). The field has the following attributes: | PKIo, RFC 3739, ETSI TS 102280 | Attributes other than those mentioned below MUST NOT be used. | |
issuer:countryName |
V | See requirements 7.1-pkio174 | ETSI TS 101862, X520, ISO 3166 | PrintableString |
|
issuer:organizationName |
V | See requirements 7.1-pkio174 | ETSI TS 102280 | UTF8String |
|
issuer:organizationalUnitName |
O | See requirements 7.1-pkio174 | ETSI TS 102280: 5.2.4 | UTF8String |
|
issuer:serialNumber |
O | See requirements 7.1-pkio174 | RFC 3739 | PrintableString |
|
issuer:commonName |
V | See requirements 7.1-pkio174 | PKIo, RFC 3739 | UTF8String |
The commonName attribute MUST NOT be necessary in order to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739) |
issuer:organizationIdentifier |
V/N | Contains an identification of the issuing TSP. This field MUST be present when the subject:organizationIdentifier is present in the TSP issuing certificate and MUST NOT be present when the subject:organizationIdentifier is NOT present in the TSP issuing certificate. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identification string is specified in paragraph 5.1.4 van ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - 2 character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and - identifier (according to country and identity type reference). |
validity |
V | MUST define the period of validity of the certificate according to RFC 5280. | RFC 5280 | UTCTime |
MUST include the start and end date for validity of the certificate in accordance with the applicable policy laid down in the CPS. |
subject |
V | The attributes that are used to describe the subject (end user) MUST mention the subject in a unique manner. The field has the following attributes: |
PKIo, RFC 3739, ETSI TS 102 280 | MUST contain a Distinguished Name (DN). Attributes other than those mentioned below MUST NOT be used. | |
subject:countryName |
V | Complete C with two-letter country code in accordance with ISO 3166-1. If an official alpha-2 code is missing, the TSP MAY use the user-assigned code XX. | RFC 3739, X520, ISO 3166, PKIo | PrintableString |
The country code that is used in subject:countryName MUST correspond with the subscribers address in accordance with the accepted document or registry. |
subject:commonName |
V | See requirement 7.1-pkio203. | RFC 3739, ETSI TS 102 280, PKIo | UTF8String |
See requirement 7.1-pkio203. |
subject:givenName |
V/O | A correct reproduction of the element of the name laid down in the CN. Based on the Compulsory Identification Act document. | RFC 3739 | UTF8String |
This field MUST show the subjects first name(s) correctly as shown on the Compulsory Identification Act document. |
subject:stateOrProvinceName |
A | The use is advised against. If present, this field MUST contain the province of the certificate holders branch in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the province MUST correspond with the certificate holders address in accordance with the GBA. The certificate holder will have to submit recent proof of his address. |
subject:localityName |
A | The use is advised against. If present, this field MUST contain the location of the certificate holder in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the domicile MUST correspond with the certificate holders address in accordance with the GBA. The certificate holder will have to submit recent proof of his address. |
subject:serialNumber |
V | Number to be determined by the TSP. The combination of commonName , organizationName and serialNumber MUST be unique within the context of the TSP. |
RFC 3739, X 520, PKIo | PrintableString |
The serialNumber is intended to distinguish between subjects with the same commonName and the same organizationName . To avoid susceptibilities a serialNumber attribute MUST be allocated to every subject. |
subjectPublicKeyInfo |
V | Contains, among other things, the public key. | ETSI TS 102 280, RFC 3279 | Contains the public key, identifies the algorithm with which the key can be used. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityKeyIdentifier |
V | No | The algorithm to generate the authorityKey MUST be created on an algorithm determined by the PA. |
ETSI TS 102 280, RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
subjectKeyIdentifier |
V | No | The algorithm to generate the subjectKey MUST be created on an algorithm determined by the PA. |
RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the subjectKey (public key of the certificate holder). |
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate. For each certificate type various bits are incorporated in the keyUsage extension. In authenticity certificates the digitalSignature bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In confidentiality certificates, keyEncipherment and dataEncipherment bits MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In certificates for the electronic signature the nonRepudiation bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. |
RFC 3739, RFC 5280, ETSI TS 102 280 | BIT STRING |
|
certificatePolicies |
V | No | MUST contain the OID of the Certificate Policy (CP) and the URI of the Certification Practice Statement (CPS), and MAY contain a user notice. The TSP SHOULD use UTF8String in the userNotice field, but MAY use IA5String . ALL certificates issued with their private key residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP+ OID [0.4.0.2042.1.2]; those issued with their private key NOT residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP OID [0.4.0.2042.1.1]. Certificates issued as EU qualified certificates to natural persons with their private key residing in a QSCD, SHOULD contain an additional ETSI QCP-n-qscd OID [0.4.0.194112.1.2], or an additional ETSI QCP-n OID of [0.4.0.194112.1.0] when their private key does not reside on a QSCD. |
RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
An overview of all Certificate Policy OIDs can be found in the document “PKIoverheid registered OIDs”. For the Citizen domain the OIDs are: - Authenticity: id-pkio-cp-g1g2g3civ-auth23 (OID: 2.16.528.1.1003.1.2.3.4 ) - Non-repudiation (eSignatures): id-pkio-cp-g1g2g3civ-nonrep23 (OID: 2.16.528.1.1003.1.2.3.5 ) - Confidentiality: id-pkio-cp-g1g2g3civ-conf23 (OID: 2.16.528.1.1003.1.2.3.6 ) Reference to the paragraph numbers of the PoR in the user notice is advised against because the persistency of this cannot be guaranteed (unlike the OID number of the CP). |
subjectAltName |
O | No | Contains one or more alternative names/identification numbers of the certificate holder | RFC 5280, PKIo, ETSI TS 102 280 | Attributes other than those mentioned below MUST NOT be used. | |
subjectAltName:otherName |
O | N/A | See requirement 7.1-pkio202. | PKIo | See description | See description. |
basicConstraints |
O | Yes | This field SHALL have its cA sub-field set to its DEFAULT value (FALSE) resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included. |
RFC 5280 | ||
cRLDistributionPoints |
V | No | MUST include the URI of a CRL distribution point. | RFC 5280, ETSI TS 102 280 | The reference MUST be accessible through the HTTP or LDAP protocol. The attribute reason MUST NOT be used, reference MUST be made to 1 CRL for all types of reasons for revocation. In addition to CRL, other types of certificate status information service MAY be supported. |
|
extKeyUsage |
V | No | RFC 5280 | See requirement 7.1-pkio149. |
Private extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityInfoAccess |
O | No | This attribute MUST include the URI of an OCSP responder if Online Certificate Status Protocol (OCSP) plays a role. | This field can optionally be used to reference other additional information about the TSP. | ||
QcStatement |
V/N | No | Certificates for the electronic signature MUST indicate that they are issued as qualified certificates complying with annex I of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qcs-QcCompliance statement in this extension. Certificates for the electronic signature MUST indicate that they are issued as type of certificate complying with annex I of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qct-esign statement in this extension. Certificates for the electronic signature MUST indicate that the private key that is part of the public key in the certificate is saved on a qualified signature creation device (QSCD) complying with annex II of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qcs-QcSSCD statement in this extension. Certificates for the electronic signature MUST contain a reference to the location of the PKI Disclosure Statement (PDS). This URL must present in the id-etsi-qcs-QcPDS statement in this extension.
The certificates for authenticity and the certificates for confidentiality MUST NOT use this extention. |
RFC 3739, ETSI TS 102 280, ETSI TS 101 862 | OBJECT IDENTIFIER |
The aforementioned QcStatement identifiers relate to the following OIDs: - id-etsi-qcs-QcCompliance { id-etsi-qcs 1 } 0.4.0.1862.1.1 - id-etsi-qct-esign { id-etsi-qcs-QcType 1 } 0.4.0.1862.1.6.1 - id-etsi-qcs-QcSSCD { id-etsi-qcs 4 } 0.4.0.1862.1.4 - id-etsi-qcs-QcPDS { id-etsi-qcs 5 } 0.4.0.1862.1.5 |
Profile for certificates under the G3 2023 Organization Person Domain
Basic attributes
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set at 2 (X.509v3). | RFC 5280 | INTEGER |
Describes the version of the certificate, the value 2 stands for X.509 version 3. |
serialNumber |
V | A serial number that MUST uniquely identify the certificate within the publishing CA domain. | RFC 5280 | INTEGER |
All end user certificates have to contain at least 8 bytes of unpredictable random data in the certificate’s serial number (serialNumber ). |
signature |
V | MUST be set on the algorithm, as stipulated by the PA. | RFC 5280, ETSI TS 102176 | OBJECT IDENTIFIER |
MUST be the same as the field signatureAlgorithm . For certificates under the G3 root certificate, only sha-256WithRSAEncryption is allowed. |
issuer |
V | MUST contain a Distinguished Name (DN). The field has the following attributes | PKIo, RFC 3739, ETSI TS 102280 | Attributes other than those mentioned below MUST NOT be used. | |
issuer:countryName |
V | See requirement 7.1-pkio174 | ETSI TS 101862, X520, ISO 3166 | PrintableString |
|
issuer:organizationName |
V | See requirement 7.1-pkio174 | ETSI TS 102280 | UTF8String |
|
issuer:organizationalUnitName |
O | See requirement 7.1-pkio174 | ETSI TS 102280: 5.2.4 | UTF8String |
|
issuer:serialNumber |
O | See requirement 7.1-pkio174 | RFC 3739 | PrintableString |
|
issuer:commonName |
V | See requirement 7.1-pkio174 | PKIo, RFC 3739 | UTF8String |
The commonName attribute MUST NOT be necessary in order to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739) |
issuer:organizationIdentifier |
V/N | Contains an identification of the issuing TSP. This field MUST be present when the subject:organizationIdentifier is present in the TSP issuing certificate and MUST NOT be present when the subject:organizationIdentifier is NOT present in the TSP issuing certificate. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identification string is specified in paragraph 5.1.4 van ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - 2 character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and - identifier (according to country and identity type reference). |
validity |
V | MUST define the period of validity of the certificate according to RFC 5280. | RFC 5280 | UTCTime |
MUST include the start and end date for validity of the certificate in accordance with the applicable policy laid down in the CPS. |
subject |
V | The attributes that are used to describe the subject (end user) MUST mention the subject in a unique manner and include information about the subscriber. The field has the following attributes |
PKIo, RFC 3739, ETSI TS 102 280 | MUST contain a Distinguished Name (DN). Attributes other than those mentioned below MUST NOT be used. | |
subject:countryName |
V | Complete C with two-letter country code in accordance with ISO 3166-1. If an official alpha-2 code is missing, the TSP MAY use the user-assigned code XX. | RFC 3739, X520, ISO 3166, PKIo | PrintableString |
The country code that is used in subject:countryName MUST correspond with the subscriber’s address in accordance with the accepted document or registry. |
subject:commonName |
V | See requirement 7.1-pkio203. | RFC 3739, ETSI TS 102 280, PKIo | UTF8String |
See requirement 7.1-pkio203. |
subject:surname |
V | A correct reproduction of the element of the name laid down in the CN. Based on the Compulsory Identification Act document. | RFC 3739 | UTF8String |
This field MUST show the subject’s surname including surname prefixes correctly, as shown on the Compulsory Identification Act document. |
subject:givenName |
V/O | A correct reproduction of the element of the name laid down in the CN. Based on the Compulsory Identification Act document. | RFC 3739 | UTF8String |
This field MUST show the subject’s surname including surname prefixes correctly, as shown on the Compulsory Identification Act document. |
subject:organizationName |
V | Full name of the subscriber in accordance with the accepted document or Basic Registry | PKIo | UTF8String |
The subscriber is the entity with which the TSP has entered into an agreement and on behalf of which or pursuant to which the certificate holder acts when using the certificate. In occupational-linked certificates this is equal to the common name of the certificate holder. |
subject:stateOrProvinceName |
A | The use is advised against. If present, this field MUST contain the province in which the subscriber is established in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the province MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:localityName |
A | The use is advised against. If present, this field MUST contain the location of the subscriber in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the location MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:serialNumber |
V | Number to be determined by the TSP. The combination of commonName , organizationName and serialNumber MUST be unique within the context of the TSP. |
RFC 3739, X 520, PKIo | PrintableString |
The serialNumber is intended to distinguish between subjects with the same commonName and the same organizationName . To avoid susceptibilities a serialNumber attribute MUST be allocated to every subject. |
subject:title |
V/N | MUST contain value from limitative list of professions in PoR requirement 3.2.5-pkio160. | ETSI TS 102 280, RFC 3739, RFC 5280 | This field SHALL only be used in certificates of the ‘professional certificate’ type. | |
subjectPublicKeyInfo |
V | Contains, among other things, the public key. | ETSI TS 102 280, RFC 3279 | Contains the public key, identifies the algorithm with which the key can be used. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityKeyIdentifier |
V | No | The algorithm to generate the authorityKey MUST be created on an algorithm determined by the PA. |
ETSI TS 102 280, RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
subjectKeyIdentifier |
V | No | The algorithm to generate the subjectKey MUST be created on an algorithm determined by the PA. |
RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the subjectKey (public key of the certificate holder). |
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate. For each certificate type various bits are incorporated in the keyUsage extension. In authenticity certificates the digitalSignature bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In confidentiality certificates, keyEncipherment and dataEncipherment bits MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In certificates for the electronic signature the nonRepudiation bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. |
RFC 3739, RFC 5280, ETSI TS 102 280 | BIT STRING |
|
certificatePolicies |
V | No | MUST contain the OID of the Certificate Policy (CP) and the URI of the Certification Practice Statement (CPS), and MAY contain a user notice. The TSP SHOULD use UTF8String in the userNotice field, but MAY use IA5String . ALL certificates issued with their private key residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP+ OID [0.4.0.2042.1.2]; those issued with their private key NOT residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP OID [0.4.0.2042.1.1]. Certificates issued as EU qualified certificates to natural persons with their private key residing in a QSCD, SHOULD contain an additional ETSI QCP-n-qscd OID [0.4.0.194112.1.2], or an additional ETSI QCP-n OID of [0.4.0.194112.1.0] when their private key does not reside on a QSCD. |
RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
An overview of all Certificate Policy OIDs can be found in the document “PKIoverheid registered OIDs”. For the Organization Person domain the OIDs are: - Authenticity: id-pkio-cp-g2g3org-auth23 (OID: 2.16.528.1.1003.1.2.5.10 ) - Non-repudiation: id-pkio-cp-g2g3org-nonrep23 (OID: 2.16.528.1.1003.1.2.5.11 ) - Confidentiality: id-pkio-cp-g2g3org-conf23 Reference to the paragraph numbers of the PoR in the user notice is advised against because the persistency of this cannot be guaranteed (unlike the OID number of the CP). |
subjectAltName |
O | No | Contains one or more alternative names/identification numbers of the certificate holder | RFC 5280, PKIo, ETSI TS 102 280 | Attributes other than those mentioned below MUST NOT be used. | |
subjectAltName:otherName |
O | N/A | See requirement 7.1-pkio202. | PKIo | See description | See description. |
basicConstraints |
O | Yes | This field SHALL have its cA sub-field set to its DEFAULT value (FALSE ) resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included. |
RFC 5280 | ||
cRLDistributionPoints |
V | No | MUST include the URI of a CRL distribution point. | RFC 5280, ETSI TS 102 280 | The reference MUST be accessible through the HTTP or LDAP protocol. The attribute reason MUST NOT be used, reference MUST be made to 1 CRL for all types of reasons for revocation. In addition to CRL, other types of certificate status information service MAY be supported. |
|
extKeyUsage |
V | No | RFC 5280 | KeyPurposeId |
See requirement 7.1-pkio149. |
Private extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityInfoAccess |
O | No | This attribute MUST include the URI of an OCSP responder if Online Certificate Status Protocol (OCSP) plays a role. | This field can optionally be used to reference other additional information about the TSP. | ||
QcStatement |
V/N | No | Certificates for the electronic signature MUST indicate that they are issued as qualified certificates complying with annex I of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qcs-QcCompliance statement in this extension. Certificates for the electronic signature MUST indicate that they are issued as type of certificate complying with annex I of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qct-esign statement in this extension. Certificates for the electronic signature MUST indicate that the private key that is part of the public key in the certificate is saved on a qualified signature creation device (QSCD) complying with annex II of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qcs-QcSSCD statement in this extension. Certificates for the electronic signature MUST contain a reference to the location of the PKI Disclosure Statement (PDS). This URL must present in the id-etsi-qcs-QcPDS statement in
this extension. The certificates for authenticity and the certificates for confidentiality MUST NOT use this extension. |
RFC 3739, ETSI TS 102 280, ETSI TS 101 862 | OBJECT IDENTIFIER |
The aforementioned QcStatement identifiers relate to the following OIDs: - id-etsi-qcs-QcCompliance { id-etsi-qcs 1 } 0.4.0.1862.1.1 - id-etsi-qct-esign { id-etsi-qcs-QcType 1 } 0.4.0.1862.1.6.1 - id-etsi-qcs-QcSSCD { id-etsi-qcs 4 } 0.4.0.1862.1.4 - id-etsi-qcs-QcPDS { id-etsi-qcs 5 } 0.4.0.1862.1.5 |
Profile for certificates under the G3 2023 Organization Services Domain
Basic attributes
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set at 2 (X.509v3). | RFC 5280 | INTEGER |
Describes the version of the certificate, the value 2 stands for X.509 version 3. |
serialNumber |
V | A serial number that MUST uniquely identify the certificate within the publishing CA domain. | RFC 5280 | INTEGER |
All end user certificates have to contain at least 8 bytes of unpredictable random data in the certificate’s serial number (serialNumber ). |
signature |
V | MUST be created on the algorithm, as stipulated by the PA. | RFC 5280, ETSI TS 102176 | OBJECT IDENTIFIER |
MUST be the same as the field signatureAlgorithm . |
issuer |
V | MUST contain a Distinguished Name (DN). The field has the following attributes: | PKIo, RFC 3739, ETSI TS 102280 | Attributes other than those mentioned below MUST NOT be used. | |
issuer:countryName |
V | See requirement 7.1-pkio174. | ETSI TS 101862, X520, ISO 3166 | PrintableString |
|
issuer:organizationName |
V | See requirement 7.1-pkio174. | ETSI TS 102280 | UTF8String |
|
issuer:organizationalUnitName |
O | See requirement 7.1-pkio174. | ETSI TS 102280 | UTF8String |
|
issuer:serialNumber |
O | See requirement 7.1-pkio174. | RFC 3739 | PrintableString |
|
issuer:commonName |
V | See requirement 7.1-pkio174. | PKIo, RFC 3739 | UTF8String |
The commonName attribute MUST NOT be needed to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739) |
issuer:organizationIdentifier |
V/N | Contains an identification of the issuing TSP. This field MUST be present when the subject:organizationIdentifier is present in the TSP issuing certificate and MUST NOT be present when the subject:organizationIdentifier is NOT present in the TSP issuing certificate. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identification string is specified in paragraph 5.1.4 van ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - 2 character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and - identifier (according to country and identity type reference). |
validity |
V | MUST define the period of validity of the certificate according to RFC 5280. | RFC 5280 | UTCTime |
MUST include the start and end date for validity of the certificate in accordance with the applicable policy laid down in the CPS. |
subject |
V | The attributes that are used to describe the subject (service) MUST mention the subject in a unique way and include information about the subscriber organization. The field has the following attributes: | PKIo, RFC 3739, ETSI TS 102 280 | MUST contain a Distinguished Name (DN). Attributes other than those mentioned below MUST NOT be used. | |
subject:countryName |
V | Complete C with two-letter country code in accordance with ISO 3166-1. If an official alpha-2 code is missing, the TSP MAY use the user-assigned code XX. | RFC 3739, X520, ISO 3166, PKIo | PrintableString |
The country code that is used in subject:countryName MUST correspond with the subscriber’s address in accordance with the accepted document or registry. |
subject:commonName |
V | See requirement 7.1-pkio204. | RFC 3739, ETSI TS 102 280, PKIo | UTF8String |
See requirement 7.1-pkio204. |
subject:organizationName |
V | The full name of the subscriber’s organization in accordance with the accepted document or Basic Registry. | PKIo | UTF8String |
The subscriber organization is the organization with which the TSP has entered into an agreement and on behalf of which the certificate holder (service) communicates or acts. |
subject:organizationIdentifier |
V | The value of the subject:organizationIdentifier field SHALL contain EITHER: - an identifier conforming to the semantics for legal person identifiers set forth in Section 5.1.4 of ETSI standard EN 319 412-1, or - an OIN/HRN number. |
ETSI EN 319 412-1 | UTF8String |
TSPs wanting to use a register for legal person identifiers which could qualify as a “national scheme” as described in ETSI standard EN 319 412-1 Section 5.1.4 can apply at Logius for a two-character encoding identifying the relevant source. These encodings will be added to the PKIo CPS. OIN/HRN identifiers adhering to the “national scheme” clause in Section 5.1.4 of ETSI standard EN 319 412-1 are preferred from a standards perspective. This will however mean many governmental systems have to be altered, making this not a likely scenario for the forseeable future. |
subject:organizationalUnitName |
A | Usage of the subject:organizationalUnitName field is discouraged. When used the value of the subject:organizationalUnitName field SHALL be an identifier of an organizational entity, the validation of which SHALL be described in the CPS of the TSP. This value SHALL NOT resemble functional roles or titles. |
PKIo | Usage of the subject:organizationalUnitName field is discouraged because it is inherently impossible to verify through independent sources with the exception of certain sub-OINs in the OIN register. Note: The dentifier of an organizational entity can be in any form, i.e. name, number, or a combination of both. |
|
subject:stateOrProvinceName |
A | The use is advised against. If present, this field MUST contain the province in which the subscriber is established in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the province MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:localityName |
A | The use is advised against. If present, this field MUST contain the location of the subscriber in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the location MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:serialNumber |
O | The TSP is responsible for safeguarding the uniqueness of the subject (service). The subject:serialNumber MUST be used to identify the subject uniquely. The use of 20 positions is only allowed for OIN and HRN after additional arrangements with Logius. |
RFC 3739, X 520, PKIo | PrintableString |
The number is determined by the TSP and/or the government. The number can differ for each domain and can be used for several applications. |
subjectPublicKeyInfo |
V | Contains, among other things, the public key. | ETSI TS 102 280, RFC 3279 | Contains the public key, identifies the algorithm with which the key can be used. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityKeyIdentifier |
V | No | The algorithm to generate the authorityKey MUST be created on an algorithm determined by the PA. |
ETSI TS 102 280, RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
subjectKeyIdentifier |
V | No | The algorithm to generate the subjectKey MUST be created on an algorithm determined by the PA. |
RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the subjectKey (public key of the certificate holder). |
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate. For each certificate type various bits are incorporated in the keyUsage extension. In authenticity certificates the digitalSignature bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In confidentiality certificates, keyEncipherment and dataEncipherment bits MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In certificates for the electronic seal the nonRepudiation bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. |
RFC 3739, RFC 5280, ETSI TS 102 280 | BIT STRING |
|
certificatePolicies |
V | No | MUST contain the OID of the Certificate Policy (CP) and the URI of the Certification Practice Statement (CPS), and MAY contain a user notice. The TSP SHOULD use UTF8String in the userNotice field, but MAY use IA5String . ALL certificates issued with their private key residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP+ OID [0.4.0.2042.1.2]; those issued with their private key NOT residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP OID [0.4.0.2042.1.1]. Certificates issued as EU qualified certificates to legal persons with their private key residing in a QSCD, SHOULD contain an additional ETSI QCP-l-qscd OID [0.4.0.194112.1.3], or an additional ETSI QCP-l OID of [0.4.0.194112.1.1] when their private key does not reside on a QSCD |
RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
An overview of all Certificate Policy OIDs can be found in the document “PKIoverheid registered OIDs”. For the Organization Services domain the OIDs are: - Authenticity: id-pkio-cp-g2g3org-svc-auth23 (OID: 2.16.528.1.1003.1.2.5.13 ) - Non-repudiation (eSeal): id-pkio-cp-g2g3org-svc-seal23 (OID: 2.16.528.1.1003.1.2.5.15 ) - Confidentiality: id-pkio-cp-g2g3org-svc-conf23 (OID: 2.16.528.1.1003.1.2.5.14 ) Reference to the paragraph numbers of the PoR in the user notice is advised against because the persistency of this cannot be guaranteed (unlike the OID number of the CP). |
subjectAltName |
O | No | Contains one or more alternative names/identification numbers of the certificate holder | RFC 5280, PKIo, ETSI TS 102 280 | Attributes other than those mentioned below MUST NOT be used. | |
subjectAltName:otherName |
O | See requirement 7.1-pkio202. | PKIo | See description | See description. | |
basicConstraints |
O | Yes | This field SHALL have its cA sub-field set to its DEFAULT value (FALSE) resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included. |
RFC 5280 | ||
cRLDistributionPoints |
V | No | MUST include the URI of a CRL distribution point. | RFC 5280, ETSI TS 102 280 | The reference MUST be accessible through the HTTP or LDAP protocol. The attribute reason MUST NOT be used, reference MUST be made to 1 CRL for all types of reasons for revocation. In addition to CRL, other types of certificate status information service MAY be supported. |
|
extKeyUsage |
V | No | RFC 5280 | KeyPurposeId s |
See requirement 7.1-pkio149. |
Private extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityInfoAccess |
O | No | This attribute MUST include the URI of an OCSP responder if Online Certificate Status Protocol (OCSP) plays a role. | This field can optionally be used to reference other additional information about the TSP. | ||
QcStatement |
V/N | No | Certificates for the electronic seals MUST indicate that they are issued as qualified certificates complying with annex III of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qcs-QcCompliance statement in this extension. Certificates for the electronic seals MUST indicate that they are issued as type of certificate complying with annex I of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qct-eseal statement in this extension. Certificates for the electronic seals MUST indicate that the private key that is part of the public key in the certificate is saved on a qualified signature creation device (QSCD) complying with annex II of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qcs-QcSSCD statement in this extension. Certificates for the electronic signature MUST contain a reference to the location of the PKI Disclosure Statement (PDS). This URL must present in the id-etsi-qcs-QcPDS statement in this
extension. |
RFC 3739, ETSI TS 102 280, ETSI TS 101 862 | OBJECT IDENTIFIER |
The aforementioned QcStatement identifiers relate to the following OIDs: - id-etsi-qcs-QcCompliance { id-etsi-qcs 1 } 0.4.0.1862.1.1 - id-etsi-qct-eseal { id-etsi-qcs-QcType 2 } 0.4.0.1862.1.6.2 - id-etsi-qcs-QcSSCD { id-etsi-qcs 4 } 0.4.0.1862.1.4 - id-etsi-qcs-QcPDS { id-etsi-qcs 5 } 0.4.0.1862.1.5 |
QcStatement-2 |
V | No | This extension munst contain an id-etsi-qcs-SemanticsId-Legal statement. This semantics identifier indicates that the organizationalIdentifier in the subject adheres to the prescribed layout. |
ETSI EN 319 412-1 | OBJECT IDENTIFIER |
Said QcStatement identifiers are the following OIDs: id-etsi-qcs-SemanticsId-Legal { id-etsi-qcs-semantics-identifiers 2 } 0.4.0.194121.1.2 |
Profile for certificates under the G3 2023 S/MIME Domain: Individual-validated only
Basic attributes
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set at 2 (X.509v3). | RFC 5280 | INTEGER |
Describes the version of the certificate, the value 2 stands for X.509 version 3. |
serialNumber |
V | See requirement 7.1-pkio173. | RFC 5280 | INTEGER |
See requirement 7.1-pkio173. |
signature |
V | MUST be created on the algorithm, as stipulated by the PA. | RFC 5280, ETSI TS 102176 | OBJECT IDENTIFIER |
MUST be the same as the field signatureAlgorithm . For certificates under the G3 root certificate, only sha-256WithRSAEncryption is allowed. |
issuer |
V | MUST contain a Distinguished Name (DN). The field has the following attributes: | PKIo, RFC 3739, ETSI TS 102280 | Attributes other than those mentioned below MUST NOT be used. | |
issuer:countryName |
V | See requirements 7.1-pkio174 | ETSI TS 101862, X520, ISO 3166 | PrintableString |
|
issuer:organizationName |
V | See requirements 7.1-pkio174 | ETSI TS 102280 | UTF8String |
|
issuer:organizationalUnitName |
O | See requirements 7.1-pkio174 | ETSI TS 102280: 5.2.4 | UTF8String |
|
issuer:serialNumber |
O | See requirements 7.1-pkio174 | RFC 3739 | PrintableString |
|
issuer:commonName |
V | See requirements 7.1-pkio174 | PKIo, RFC 3739 | UTF8String |
The commonName attribute MUST NOT be necessary in order to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739) |
issuer:organizationIdentifier |
V/N | Contains an identification of the issuing TSP. This field MUST be present when the subject:organizationIdentifier is present in the TSP issuing certificate and MUST NOT be present when the subject:organizationIdentifier is NOT present in the TSP issuing certificate. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identification string is specified in paragraph 5.1.4 van ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - 2 character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and - identifier (according to country and identity type reference). |
validity |
V | MUST define the period of validity of the certificate according to RFC 5280. | RFC 5280 | UTCTime |
MUST include the start and end date for validity of the certificate in accordance with the applicable policy laid down in the CPS. |
subject |
V | The attributes that are used to describe the subject (end user) MUST mention the subject in a unique manner. The field has the following attributes: |
PKIo, RFC 3739, ETSI TS 102 280 | MUST contain a Distinguished Name (DN). Attributes other than those mentioned below MUST NOT be used. | |
subject:countryName |
V | Complete C with two-letter country code in accordance with ISO 3166-1. If an official alpha-2 code is missing, the TSP MAY use the user-assigned code XX. | RFC 3739, X520, ISO 3166, PKIo | PrintableString |
The country code that is used in subject:countryName MUST correspond with the subscribers address in accordance with the accepted document or registry. |
subject:commonName |
V | See requirement 7.1-pkio203. | RFC 3739, ETSI TS 102 280, PKIo | UTF8String |
See requirement 7.1-pkio203. |
subject:givenName |
V/O | A correct reproduction of the element of the name laid down in the CN. Based on the Compulsory Identification Act document. | RFC 3739 | UTF8String |
This field MUST show the subjects first name(s) correctly as shown on the Compulsory Identification Act document. |
subject:stateOrProvinceName |
A | The use is advised against. If present, this field MUST contain the province of the certificate holders branch in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the province MUST correspond with the certificate holders address in accordance with the GBA. The certificate holder will have to submit recent proof of his address. |
subject:localityName |
A | The use is advised against. If present, this field MUST contain the location of the certificate holder in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the domicile MUST correspond with the certificate holders address in accordance with the GBA. The certificate holder will have to submit recent proof of his address. |
subject:serialNumber |
V | Number to be determined by the TSP. The combination of commonName , organizationName and serialNumber MUST be unique within the context of the TSP. |
RFC 3739, X 520, PKIo | PrintableString |
The serialNumber is intended to distinguish between subjects with the same commonName and the same organizationName . To avoid susceptibilities a serialNumber attribute MUST be allocated to every subject. |
subjectPublicKeyInfo |
V | Contains, among other things, the public key. | ETSI TS 102 280, RFC 3279 | Contains the public key, identifies the algorithm with which the key can be used. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityKeyIdentifier |
V | No | The algorithm to generate the authorityKey MUST be created on an algorithm determined by the PA. |
ETSI TS 102 280, RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
subjectKeyIdentifier |
V | No | The algorithm to generate the subjectKey MUST be created on an algorithm determined by the PA. |
RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the subjectKey (public key of the certificate holder). |
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate. The keyUsage extension SHALL have active digitalSignature (0) and keyEncipherment (2) bits, and MAY have an active nonRepudiation (1) bit. Other bits SHALL NOT be active. |
RFC 3739, RFC 5280, ETSI TS 102 280 | BIT STRING |
|
certificatePolicies |
V | No | MUST contain the OID of the Certificate Policy (CP) and the URI of the Certification Practice Statement (CPS), and MAY contain a user notice. The TSP SHOULD use UTF8String in the userNotice field, but MAY use IA5String . ALL certificates issued with their private key residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP+ OID [0.4.0.2042.1.2]; those issued with their private key NOT residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP OID [0.4.0.2042.1.1]. Certificates issued as EU qualified certificates to natural persons with their private key residing in a QSCD, SHOULD contain an additional ETSI QCP-n-qscd OID [0.4.0.194112.1.2], or an additional ETSI QCP-n OID of [0.4.0.194112.1.0] when their private key does not reside on a QSCD. |
RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
An overview of all Certificate Policy OIDs can be found in the document “PKIoverheid registered OIDs”. For the Individual-validated domain the PKIoverheid OID is: - Strict: 2.16.528.1.1003.1.2.12.9 |
subjectAltName |
V | No | Contains one or more alternative names/identification numbers of the certificate holder | RFC 5280, PKIo, ETSI TS 102 280 | Attributes other than those mentioned below MUST NOT be used. | |
subjectAltName:rfc822Name |
V | SHALL be used for the certificate holder’s e-mail address, for applications that need the e-mail address to be able to function properly. | RFC 5280 | IA5String |
||
basicConstraints |
O | Yes | This field SHALL have its cA sub-field set to its DEFAULT value (FALSE) resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included. |
RFC 5280 | ||
cRLDistributionPoints |
V | No | MUST include the URI of a CRL distribution point. | RFC 5280, ETSI TS 102 280 | The reference MUST be accessible through the HTTP or LDAP protocol. The attribute reason MUST NOT be used, reference MUST be made to 1 CRL for all types of reasons for revocation. In addition to CRL, other types of certificate status information service MAY be supported. |
|
extKeyUsage |
V | No | RFC 5280 | See requirement 7.1-pkio149. |
Private extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityInfoAccess |
O | No | This attribute MUST include the URI of an OCSP responder if Online Certificate Status Protocol (OCSP) plays a role. | This field can optionally be used to reference other additional information about the TSP. |
Profile for certificates under the G3 2023 S/MIME Domain: Sponsor-validated only
Basic attributes
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set at 2 (X.509v3). | RFC 5280 | INTEGER |
Describes the version of the certificate, the value 2 stands for X.509 version 3. |
serialNumber |
V | See requirement 7.1-pkio173. | RFC 5280 | INTEGER |
See requirement 7.1-pkio173. |
signature |
V | MUST be set on the algorithm, as stipulated by the PA. | RFC 5280, ETSI TS 102176 | OBJECT IDENTIFIER |
MUST be the same as the field signatureAlgorithm . For certificates under the G3 root certificate, only sha-256WithRSAEncryption is allowed. |
issuer |
V | MUST contain a Distinguished Name (DN). The field has the following attributes | PKIo, RFC 3739, ETSI TS 102280 | Attributes other than those mentioned below MUST NOT be used. | |
issuer:countryName |
V | See requirement 7.1-pkio174 | ETSI TS 101862, X520, ISO 3166 | PrintableString |
|
issuer:organizationName |
V | See requirement 7.1-pkio174 | ETSI TS 102280 | UTF8String |
|
issuer:organizationalUnitName |
O | See requirement 7.1-pkio174 | ETSI TS 102280: 5.2.4 | UTF8String |
|
issuer:serialNumber |
O | See requirement 7.1-pkio174 | RFC 3739 | PrintableString |
|
issuer:commonName |
V | See requirement 7.1-pkio174 | PKIo, RFC 3739 | UTF8String |
The commonName attribute MUST NOT be necessary in order to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739) |
issuer:organizationIdentifier |
V/N | Contains an identification of the issuing TSP. This field MUST be present when the subject:organizationIdentifier is present in the TSP issuing certificate and MUST NOT be present when the subject:organizationIdentifier is NOT present in the TSP issuing certificate. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identification string is specified in paragraph 5.1.4 van ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - 2 character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and - identifier (according to country and identity type reference). |
validity |
V | MUST define the period of validity of the certificate according to RFC 5280. | RFC 5280 | UTCTime |
MUST include the start and end date for validity of the certificate in accordance with the applicable policy laid down in the CPS. |
subject |
V | The attributes that are used to describe the subject (end user) MUST mention the subject in a unique manner and include information about the subscriber. The field has the following attributes |
PKIo, RFC 3739, ETSI TS 102 280 | MUST contain a Distinguished Name (DN). Attributes other than those mentioned below MUST NOT be used. | |
subject:countryName |
V | Complete C with two-letter country code in accordance with ISO 3166-1. If an official alpha-2 code is missing, the TSP MAY use the user-assigned code XX. | RFC 3739, X520, ISO 3166, PKIo | PrintableString |
The country code that is used in subject:countryName MUST correspond with the subscriber’s address in accordance with the accepted document or registry. |
subject:commonName |
V | See requirement 7.1-pkio203. | RFC 3739, ETSI TS 102 280, PKIo | UTF8String |
See requirement 7.1-pkio203. |
subject:surname |
V | A correct reproduction of the element of the name laid down in the CN. Based on the Compulsory Identification Act document. | RFC 3739 | UTF8String |
This field MUST show the subject’s surname including surname prefixes correctly, as shown on the Compulsory Identification Act document. |
subject:givenName |
V/O | A correct reproduction of the element of the name laid down in the CN. Based on the Compulsory Identification Act document. | RFC 3739 | UTF8String |
This field MUST show the subject’s surname including surname prefixes correctly, as shown on the Compulsory Identification Act document. |
subject:organizationName |
V | Full name of the subscriber in accordance with the accepted document or Basic Registry | PKIo | UTF8String |
The subscriber is the entity with which the TSP has entered into an agreement and on behalf of which or pursuant to which the certificate holder acts when using the certificate. In occupational-linked certificates this is equal to the common name of the certificate holder. |
subject:organizationIdentifier |
V | Refer to SBRG section 7.1.4.2.2 clause d. | ETSI EN 319 412-1 | UTF8String |
Refer to SBRG section 7.1.4.2.2 clause d. |
subject:stateOrProvinceName |
A | The use is advised against. If present, this field MUST contain the province in which the subscriber is established in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the province MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:localityName |
A | The use is advised against. If present, this field MUST contain the location of the subscriber in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the location MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:serialNumber |
V | Number to be determined by the TSP. The combination of commonName , organizationName and serialNumber MUST be unique within the context of the TSP. |
RFC 3739, X 520, PKIo | PrintableString |
The serialNumber is intended to distinguish between subjects with the same commonName and the same organizationName . To avoid susceptibilities a serialNumber attribute MUST be allocated to every subject. |
subject:title |
V/N | MUST contain value from limitative list of professions in PoR requirement 3.2.5-pkio160. | ETSI TS 102 280, RFC 3739, RFC 5280 | This field SHALL only be used in certificates of the ‘professional certificate’ type. | |
subjectPublicKeyInfo |
V | Contains, among other things, the public key. | ETSI TS 102 280, RFC 3279 | Contains the public key, identifies the algorithm with which the key can be used. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityKeyIdentifier |
V | No | The algorithm to generate the authorityKey MUST be created on an algorithm determined by the PA. |
ETSI TS 102 280, RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
subjectKeyIdentifier |
V | No | The algorithm to generate the subjectKey MUST be created on an algorithm determined by the PA. |
RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the subjectKey (public key of the certificate holder). |
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate.The keyUsage extension SHALL have active digitalSignature (0) and keyEncipherment (2) bits, and MAY have an active nonRepudiation (1) bit. Other bits SHALL NOT be active. |
RFC 3739, RFC 5280, ETSI TS 102 280 | BIT STRING |
|
certificatePolicies |
V | No | MUST contain the OID of the Certificate Policy (CP) and the URI of the Certification Practice Statement (CPS), and MAY contain a user notice. The TSP SHOULD use UTF8String in the userNotice field, but MAY use IA5String . ALL certificates issued with their private key residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP+ OID [0.4.0.2042.1.2]; those issued with their private key NOT residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP OID [0.4.0.2042.1.1]. Certificates issued as EU qualified certificates to natural persons with their private key residing in a QSCD, SHOULD contain an additional ETSI QCP-n-qscd OID [0.4.0.194112.1.2], or an additional ETSI QCP-n OID of [0.4.0.194112.1.0] when their private key does not reside on a QSCD. |
RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
An overview of all Certificate Policy OIDs can be found in the document “PKIoverheid registered OIDs”. For the Sponsor-validated domain the PKIoverheid OID is: - Strict: 2.16.528.1.1003.1.2.10.9 |
subjectAltName |
V | No | Contains one or more alternative names/identification numbers of the certificate holder | RFC 5280, PKIo, ETSI TS 102 280 | Attributes other than those mentioned below MUST NOT be used. | |
subjectAltName:rfc822Name |
V | SHALL be used for the certificate holder’s e-mail address, for applications that need the e-mail address to be able to function properly. | RFC 5280 | IA5String |
||
basicConstraints |
O | Yes | This field SHALL have its cA sub-field set to its DEFAULT value (FALSE ) resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included. |
RFC 5280 | ||
cRLDistributionPoints |
V | No | MUST include the URI of a CRL distribution point. | RFC 5280, ETSI TS 102 280 | The reference MUST be accessible through the HTTP or LDAP protocol. The attribute reason MUST NOT be used, reference MUST be made to 1 CRL for all types of reasons for revocation. In addition to CRL, other types of certificate status information service MAY be supported. |
|
extKeyUsage |
V | No | RFC 5280 | KeyPurposeId |
See requirement 7.1-pkio149. |
Private extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityInfoAccess |
O | No | This attribute MUST include the URI of an OCSP responder if Online Certificate Status Protocol (OCSP) plays a role. | This field can optionally be used to reference other additional information about the TSP. |
Profile for certificates under the G3 2023 S/MIME Domain: Organization-validated only
Basic attributes
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set at 2 (X.509v3). | RFC 5280 | INTEGER |
Describes the version of the certificate, the value 2 stands for X.509 version 3. |
serialNumber |
V | See requirement 7.1-pkio173. | RFC 5280 | INTEGER |
All See requirement 7.1-pkio173. |
signature |
V | MUST be created on the algorithm, as stipulated by the PA. | RFC 5280, ETSI TS 102176 | OBJECT IDENTIFIER |
MUST be the same as the field signatureAlgorithm . |
issuer |
V | MUST contain a Distinguished Name (DN). The field has the following attributes: | PKIo, RFC 3739, ETSI TS 102280 | Attributes other than those mentioned below MUST NOT be used. | |
issuer:countryName |
V | See requirement 7.1-pkio174. | ETSI TS 101862, X520, ISO 3166 | PrintableString |
|
issuer:organizationName |
V | See requirement 7.1-pkio174. | ETSI TS 102280 | UTF8String |
|
issuer:organizationalUnitName |
O | See requirement 7.1-pkio174. | ETSI TS 102280 | UTF8String |
|
issuer:serialNumber |
O | See requirement 7.1-pkio174. | RFC 3739 | PrintableString |
|
issuer:commonName |
V | See requirement 7.1-pkio174. | PKIo, RFC 3739 | UTF8String |
The commonName attribute MUST NOT be needed to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739) |
issuer:organizationIdentifier |
V/N | Contains an identification of the issuing TSP. This field MUST be present when the subject:organizationIdentifier is present in the TSP issuing certificate and MUST NOT be present when the subject:organizationIdentifier is NOT present in the TSP issuing certificate. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identification string is specified in paragraph 5.1.4 van ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - 2 character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and - identifier (according to country and identity type reference). |
validity |
V | MUST define the period of validity of the certificate according to RFC 5280. | RFC 5280 | UTCTime |
MUST include the start and end date for validity of the certificate in accordance with the applicable policy laid down in the CPS. |
subject |
V | The attributes that are used to describe the subject (service) MUST mention the subject in a unique way and include information about the subscriber organization. The field has the following attributes: | PKIo, RFC 3739, ETSI TS 102 280 | MUST contain a Distinguished Name (DN). Attributes other than those mentioned below MUST NOT be used. | |
subject:countryName |
V | Complete C with two-letter country code in accordance with ISO 3166-1. If an official alpha-2 code is missing, the TSP MAY use the user-assigned code XX. | RFC 3739, X520, ISO 3166, PKIo | PrintableString |
The country code that is used in subject:countryName MUST correspond with the subscriber’s address in accordance with the accepted document or registry. |
subject:commonName |
V | See requirement 7.1-pkio204. | RFC 3739, ETSI TS 102 280, PKIo | UTF8String |
See requirement 7.1-pkio204. |
subject:organizationName |
V | The full name of the subscriber’s organization in accordance with the accepted document or Basic Registry. | PKIo | UTF8String |
The subscriber organization is the organization with which the TSP has entered into an agreement and on behalf of which the certificate holder (service) communicates or acts. |
subject:organizationIdentifier |
V | Refer to SBRG section 7.1.4.2.2 clause d. | ETSI EN 319 412-1 | UTF8String |
Refer to SBRG section 7.1.4.2.2 clause d. |
subject:stateOrProvinceName |
A | The use is advised against. If present, this field MUST contain the province in which the subscriber is established in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the province MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:localityName |
A | The use is advised against. If present, this field MUST contain the location of the subscriber in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the location MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:serialNumber |
O | The TSP is responsible for safeguarding the uniqueness of the subject (service). The subject:serialNumber MUST be used to identify the subject uniquely. OINs are NOT allowed. |
RFC 3739, X 520, PKIo | PrintableString |
The number is determined by the TSP and/or the government. The number can differ for each domain and can be used for several applications. |
subjectPublicKeyInfo |
V | Contains, among other things, the public key. | ETSI TS 102 280, RFC 3279 | Contains the public key, identifies the algorithm with which the key can be used. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityKeyIdentifier |
V | No | The algorithm to generate the authorityKey MUST be created on an algorithm determined by the PA. |
ETSI TS 102 280, RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
subjectKeyIdentifier |
V | No | The algorithm to generate the subjectKey MUST be created on an algorithm determined by the PA. |
RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the subjectKey (public key of the certificate holder). |
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate. The keyUsage extension SHALL have active digitalSignature (0) and keyEncipherment (2) bits, and MAY have an active nonRepudiation (1) bit. Other bits SHALL NOT be active. |
RFC 3739, RFC 5280, ETSI TS 102 280 | BIT STRING |
|
certificatePolicies |
V | No | MUST contain the OID of the Certificate Policy (CP) and the URI of the Certification Practice Statement (CPS), and MAY contain a user notice. The TSP SHOULD use UTF8String in the userNotice field, but MAY use IA5String . ALL certificates issued with their private key residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP+ OID [0.4.0.2042.1.2]; those issued with their private key NOT residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP OID [0.4.0.2042.1.1]. Certificates issued as EU qualified certificates to legal persons with their private key residing in a QSCD, SHOULD contain an additional ETSI QCP-l-qscd OID [0.4.0.194112.1.3], or an additional ETSI QCP-l OID of [0.4.0.194112.1.1] when their private key does not reside on a QSCD |
RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
An overview of all Certificate Policy OIDs can be found in the document “PKIoverheid registered OIDs”. For the Organization-validated domain the PKIoverheid OID is: - Strict: 2.16.528.1.1003.1.2.11.9 |
subjectAltName |
V | No | Contains one or more alternative names/identification numbers of the certificate holder | RFC 5280, PKIo, ETSI TS 102 280 | Attributes other than those mentioned below MUST NOT be used. | |
subjectAltName:rfc822Name |
V | SHALL be used for the service’s e-mail address, for applications that need the e-mail address in order to be able to function properly. | RFC 5280 | IA5String |
||
basicConstraints |
O | Yes | This field SHALL have its cA sub-field set to its DEFAULT value (FALSE) resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included. |
RFC 5280 | ||
cRLDistributionPoints |
V | No | MUST include the URI of a CRL distribution point. | RFC 5280, ETSI TS 102 280 | The reference MUST be accessible through the HTTP or LDAP protocol. The attribute reason MUST NOT be used, reference MUST be made to 1 CRL for all types of reasons for revocation. In addition to CRL, other types of certificate status information service MAY be supported. |
|
extKeyUsage |
V | No | RFC 5280 | KeyPurposeId s |
See requirement 7.1-pkio149. |
Private extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityInfoAccess |
O | No | This attribute MUST include the URI of an OCSP responder if Online Certificate Status Protocol (OCSP) plays a role. | This field can optionally be used to reference other additional information about the TSP. | ||
QcStatement-2 |
V | No | This extension munst contain an id-etsi-qcs-SemanticsId-Legal statement. This semantics identifier indicates that the organizationalIdentifier in the subject adheres to the prescribed layout. |
ETSI EN 319 412-1 | OBJECT IDENTIFIER |
Said QcStatement identifiers are the following OIDs: id-etsi-qcs-SemanticsId-Legal { id-etsi-qcs-semantics-identifiers 2 } 0.4.0.194121.1.2 |
Profile for certificates under the Private Organization Services Domain
Basic attributes
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set at 2 (X.509v3). | RFC 5280 | INTEGER |
Describes the version of the certificate, the value 2 stands for X.509 version 3. |
serialNumber |
V | A serial number that MUST uniquely identify the certificate within the publishing CA domain. | RFC 5280 | INTEGER |
All end user certificates have to contain at least 8 bytes of unpredictable random data in the certificate’s serial number (serialNumber ). |
signature |
V | MUST be created on the algorithm, as stipulated by the PA. | RFC 5280, ETSI TS 102176 | OBJECT IDENTIFIER |
This certificate MUST at least contain a 2048 bit RSA key. |
issuer |
V | MUST contain a Distinguished Name (DN). The field contains the following attributes: | PKIo, RFC 3739, ETSI TS 102280 | Attributes other than those mentioned below MUST NOT be used. | |
issuer:countryName |
V | See requirement 7.1-pkio174. | ETSI TS 101862, X520, ISO 3166 | PrintableString |
|
issuer:organizationName |
V | See requirement 7.1-pkio174. | ETSI TS 102280 | UTF8String |
|
issuer:organizationalUnitName |
O | See requirement 7.1-pkio174. | ETSI TS 102280 | UTF8String |
|
issuer:serialNumber |
O | See requirement 7.1-pkio174. | RFC 3739 | PrintableString |
|
issuer:commonName |
V | See requirement 7.1-pkio174. | PKIo, RFC 3739 | UTF8String |
The commonName attribute MUST NOT be needed to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739) |
issuer:organizationIdentifier |
V/N | Contains an identification of the issuing TSP. This field MUST be present when the subject:organizationIdentifier is present in the TSP issuing certificate and MUST NOT be present when the subject:organizationIdentifier is NOT present in the TSP issuing certificate. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identification string is specified in paragraph 5.1.4 van ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - 2 character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and - identifier (according to country and identity type reference). |
validity |
V | MUST define the period of validity of the certificate according to RFC 5280. | RFC 5280 | UTCTime |
MUST include the start and end date for validity of the certificate in accordance with the applicable policy laid down in the CPS. |
subject |
V | The attributes that are used to describe the subject (service) MUST mention the subject in a unique way and include information about the subscriber organization. The field has the following attributes: |
PKIo, RFC 3739, ETSI TS 102 280 | MUST contain a Distinguished Name (DN). Attributes other than those mentioned below MUST NOT be used. | |
subject:countryName |
V | Complete C with two-letter country code in accordance with ISO 3166-1. If an official alpha-2 code is missing, the TSP MAY use the user-assigned code XX. | RFC 3739, X520, ISO 3166, PKIo | PrintableString |
The country code that is used in subject:countryName MUST correspond with the subscriber’s address in accordance with the accepted document or registry. |
subject:commonName |
V | See requirement 7.1-pkio204. | RFC 3739, ETSI TS 102 280, PKIo | UTF8String |
See requirement 7.1-pkio204. |
subject:organizationName |
V | The full name of the subscriber’s organization in accordance with the accepted document or Basic Registry. | PKIo | UTF8String |
The subscriber organization is the organization with which the TSP has entered into an agreement and on behalf of which the certificate holder (service/server) communicates or acts. |
subject:organizationIdentifier |
V | The value of the subject:organizationIdentifier field SHALL contain EITHER: - an identifier conforming to the semantics for legal person identifiers set forth in Section 5.1.4 of ETSI standard EN 319 412-1, or - an OIN/HRN number. |
ETSI EN 319 412-1 | UTF8String |
TSPs wanting to use a register for legal person identifiers which could qualify as a “national scheme” as described in ETSI standard EN 319 412-1 Section 5.1.4 can apply at Logius for a two-character encoding identifying the relevant source. These encodings will be added to the PKIo CPS. OIN/HRN identifiers adhering to the “national scheme” clause in Section 5.1.4 of ETSI standard EN 319 412-1 are preferred from a standards perspective. This will however mean many governmental systems have to be altered, making this not a likely scenario for the forseeable future. |
subject:organizationalUnitName |
A | Usage of the subject:organizationalUnitName field is discouraged. When used the value of the subject:organizationalUnitName field SHALL be an identifier of an organizational entity, the validation of which SHALL be described in the CPS of the TSP. This value SHALL NOT resemble functional roles or titles. |
PKIo | Usage of the subject:organizationalUnitName field is discouraged because it is inherently impossible to verify through independent sources with the exception of certain sub-OINs in the OIN register. Note: The dentifier of an organizational entity can be in any form, i.e. name, number, or a combination of both. |
|
subject:stateOrProvinceName |
A | The use is advised against. If present, this field MUST contain the province in which the subscriber is established in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the province MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:localityName |
A | The use is advised against. If present, this field MUST contain the location of the subscriber in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the location MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:serialNumber |
O | The TSP is responsible for safeguarding the uniqueness of the subject (service). The subject:serialNumber MUST be used to identify the subject uniquely. The use of 20 positions is only allowed for OIN and HRN after additional arrangements with Logius. |
RFC 3739, X 520, PKIo | PrintableString |
The number is determined by the TSP and/or the government. The number can differ for each domain and can be used for several applications. |
subjectPublicKeyInfo |
V | Contains, among other things, the public key. | ETSI TS 102 280, RFC 3279 | Contains the public key, identifies the algorithm with which the key can be used. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityKeyIdentifier |
V | No | The algorithm to generate the authorityKey MUST be created on an algorithm determined by the PA. |
ETSI TS 102 280, RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
subjectKeyIdentifier |
V | No | The algorithm to generate the subjectKey MUST be created on an algorithm determined by the PA. |
RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the subjectKey (public key of the certificate holder). |
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate. For each certificate type various bits are incorporated in the keyUsage extension. In authenticity certificates the digitalSignature bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In confidentiality certificates, keyEncipherment and dataEncipherment bits MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. |
RFC 3739, RFC 5280, ETSI TS 102 280 | BIT STRING |
|
certificatePolicies |
V | No | MUST contain the OID of the Certificate Policy (CP) and the URI of the Certification Practice Statement (CPS), and MAY contain a user notice. The TSP SHOULD use UTF8String in the userNotice field, but MAY use IA5String . ALL certificates issued with their private key residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP+ OID [0.4.0.2042.1.2]; those issued with their private key NOT residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP OID [0.4.0.2042.1.1]. Certificates issued as EU qualified certificates to natural persons with their private key residing in a QSCD, SHOULD contain an additional ETSI QCP-l-qscd OID [0.4.0.194112.1.3], or an additional ETSI QCP-l OID of [0.4.0.194112.1.1] when their private key does not reside on a QSCD. |
RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
An overview of all Certificate Policy OIDs can be found in the document “PKIoverheid registered OIDs”. In the Private Services domain the OIDs for Authenticity and Confidentiality certificates are: - Authenticity: 2.16.528.1.1003.1.2.8.4 - Confidentiality: 2.16.528.1.1003.1.2.8.5 Reference to the paragraph numbers of the PoR in the user notice is advised against because the persistency of this cannot be guaranteed (unlike the OID number of the CP). |
subjectAltName |
O | No | Contains one or more alternative names/identification numbers of the certificate holder | RFC 5280, PKIo, ETSI TS 102 280 | Attributes other than those mentioned below MUST NOT be used. | |
subjectAltName:otherName |
O | N/A | See requirement 7.1-pkio202. | PKIo | See description | See description. |
subjectAltName:rfc822Name |
A | N/A | MAY be used for the service’s e-mail address, for applications that need the e-mail address in order to be able to function properly. | RFC 5280 | IA5String |
For PKIoverheid certificates, the use of e-mail addresses is advised against, because e-mail addresses of certificate holders often change and are susceptible to spam. |
basicConstraints |
O | Yes | This field SHALL have its cA sub-field set to its DEFAULT value (FALSE) resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included. |
RFC 5280 | ||
cRLDistributionPoints |
V | No | MUST include the URI of a CRL distribution point. | RFC 5280, ETSI TS 102 280 | The reference MUST be accessible through the HTTP or LDAP protocol. The attribute reason MUST NOT be used, reference MUST be made to 1 CRL for all types of reasons for revocation. In addition to CRL, other types of certificate status information service MAY be supported. |
|
extKeyUsage |
V | No | RFC 5280 | KeyPurposeId |
See requirement 7.1-pkio149. |
Private extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityInfoAccess |
O | No | This attribute MUST include the URI of an OCSP responder if Online Certificate Status Protocol (OCSP) plays a role. | This field can optionally be used to reference other additional information about the TSP. |
Profile for certificates under the Private Server domain
Basic attributes
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set at 2 (X.509v3). | RFC 5280 | INTEGER |
Describes the version of the certificate, the value 2 stands for X.509 version 3. |
serialNumber |
V | A serial number that MUST uniquely identify the certificate within the publishing CA domain. | RFC 5280 | INTEGER |
All end user certificates have to contain at least 8 bytes of unpredictable random data in the certificate’s serial number (serialNumber ). |
signature |
V | MUST be created on the algorithm, as stipulated by the PA. | RFC 5280, ETSI TS 102176 | OBJECT IDENTIFIER |
This certificate MUST contain at least a 2048 bit RSA key. |
issuer |
V | MUST contain a Distinguished Name (DN). The field contains the following attributes: | PKIo, RFC 3739, ETSI TS 102280 | Attributes other than those mentioned below MUST NOT be used. | |
issuer:countryName |
V | See requirement 7.1-pkio174. | ETSI TS 101862, X520, ISO 3166 | PrintableString |
|
issuer:organizationName |
V | See requirement 7.1-pkio174. | ETSI TS 102280 | UTF8String |
|
issuer:organizationalUnitName |
O | See requirement 7.1-pkio174. | ETSI TS 102280 | UTF8String |
|
issuer:serialNumber |
O | See requirement 7.1-pkio174. | RFC 3739 | PrintableString |
|
issuer:commonName |
V | See requirement 7.1-pkio174. | PKIo, RFC 3739 | UTF8String |
The commonName attribute MUST NOT be needed to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739) |
issuer:organizationIdentifier |
V/N | Contains an identification of the issuing TSP. This field MUST be present when the subject:organizationIdentifier is present in the TSP issuing certificate and MUST NOT be present when the subject:organizationIdentifier is NOT present in the TSP issuing certificate. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identification string is specified in paragraph 5.1.4 van ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - 2 character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); - identifier (according to country and identity type reference). |
validity |
V | MUST define the period of validity of the certificate according to RFC 5280. | RFC 5280 | UTCTime |
MUST include the start and end date for validity of the certificate in accordance with the applicable policy laid down in the CPS. |
subject |
V | The attributes that are used to describe the subject (service) MUST mention the subject in a unique way and include information about the subscriber organization. The field has the following attributes: |
PKIo, RFC 3739, ETSI TS 102 280 | MUST contain a Distinguished Name (DN). Attributes other than those mentioned below MUST NOT be used. | |
subject:countryName |
V | Complete C with two-letter country code in accordance with ISO 3166-1. If an official alpha-2 code is missing, the TSP MAY use the user-assigned code XX. | RFC 3739, X520, ISO 3166, PKIo | PrintableString |
The country code that is used in subject:countryNam e MUST correspond with the subscriber’s address in accordance with the accepted document or registry. |
subject:commonName |
A | Name that identifies the server. | RFC 3739, ETSI TS 102 280, PKIo | UTF8String |
See requirement 7.1-pkio165 for requirements for the content of this field. See requirement 3.2.5-pkio162 for validation. |
subject:organizationName |
V | The full name of the subscriber’s organization in accordance with the accepted document or Basic Registry. | PKIo | UTF8String |
The subscriber organization is the organization with which the TSP has entered into an agreement and on behalf of which the certificate holder (service / server) communicates or acts. |
subject:stateOrProvinceName |
O | The use of this attribute is advised against. If present it MUST include the province of the subscriber’s branch, in accordance with the accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the province MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:localityName |
A | The use of this attribute is advised against. If present it MUST include the location of the subscriber, in accordance with the accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the location MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:serialNumber |
O | The TSP is responsible for safeguarding the uniqueness of the subject (service). The subject:serialNumber MUST be used to identify the subject uniquely. The use of 20 positions is only allowed for OIN and HRN after additional arrangements with Logius. |
RFC 3739, X 520, PKIo | PrintableString |
The number is determined by the TSP and/or the government. The number can differ for each domain and can be used for several applications. |
subjectPublicKeyInfo |
V | Contains, among other things, the public key. | ETSI TS 102 280, RFC 3279 | Contains the public key, identifies the algorithm with which the key can be used. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityKeyIdentifier |
V | No | The algorithm to generate the authorityKey MUST be created on an algorithm determined by the PA. |
ETSI TS 102 280, RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
subjectKeyIdentifier |
V | No | The algorithm to generate the subjectKey MUST be created on an algorithm determined by the PA. |
RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the subjectKey (public key of the certificate holder). |
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate. In the PKI for the government, for each certificate type various bits are incorporated in the keyUsage extension. In server certificates the digitalSignature and keyEncipherment bits MUST be incorporated and marked as being critical. Another keyUsage bit MUST NOT be combined with this. |
RFC 3739, RFC 5280, ETSI TS 102 280 | BIT STRING |
|
certificatePolicies |
V | No | MUST contain the OID of the Certificate Policy (CP) and the URI of the Certification Practice Statement (CPS), and MAY contain a user notice. The TSP SHOULD use UTF8String in the userNotice field, but MAY use IA5String . |
RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
An overview of all Certificate Policy OIDs can be found in the document “PKIoverheid registered OIDs”. In the Private Services domain the OID for Server certificates is: - Server: 2.16.528.1.1003.1.2.8.6 Reference to the paragraph numbers of the PoR in the user notice is advised against because the persistency of this cannot be guaranteed (unlike the OID number of the CP). |
subjectAltName |
V/O | No | Contains one or more alternative identifiers for subject | RFC 5280, PKIo, ETSI TS 102 280 | Attributes other than those mentioned below MUST NOT be used. | |
subjectAltName:dNSName |
V/O | N/A | Name that identifies the server. | RFC 2818, RFC 5280 | IA5String |
See requirement 7.1-pkio165 for requirements for the content of this field. See requirement 3.2.5-pkio162 for validation requirements. |
subjectAltName:iPAddress |
A | N/A | Contains a public IP address | RFC 5280, RFC 791, RFC 2460 | OCTET STRING |
See requirement 7.1-pkio165 for requirements for the content of this field. See requirement 3.2.5-pkio162 for validation requirements for the data entered in this field. |
subjectAltName:otherName |
O | N/A | See requirement 7.1-pkio202. | PKIo | See description | See description. |
basicConstraints |
O | Yes | This field SHALL have its cA sub-field set to its DEFAULT value (FALSE ) resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included. |
RFC 5280 | ITU-T Recommendation X.690 (07/2002) on ASN.1 encoding rules states in Section 5.8: “The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value”. Stating in the description that “encoded certificates do NOT include the cA sub-field” therefore is redundant. However, in the past some TSPs employed CA-issuing software which did not do proper ASN.1 encoding resulting in a wrongfully included cA sub-field in encoded certificates. This encoding error resulted in some PKIX software rejecting these certificates. This redundant information therefore has to be regarded as a cautionary hint for TSPs to check their actual certificate encoding for these errors. Chances of this encoding bug still existing in ASN.1 encoding software are however slim since the last mention of such a bug on BugZilla is from 2016. |
|
cRLDistributionPoints |
V | No | MUST include the URI of a CRL distribution point. | RFC 5280, ETSI TS 102 280 | The reference MUST be accessible through the HTTP or LDAP protocol. The attribute reason MUST NOT be used, reference MUST be made to 1 CRL for all types of reasons for revocation. In addition to CRL, other types of certificate status information service MAY be supported. |
|
extKeyUsage |
V | No | extension that indicates for which application the certificate can be used. | RFC 5280 | KeyPurposeId s |
See requirement 7.1-pkio149. |
Private extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityInfoAccess |
O | No | This attribute MUST include the URI of an OCSP responder if Online Certificate Status Protocol (OCSP) plays a role. | This field can optionally be used to reference other additional information about the TSP. |
Profile for certificates under the Private Persons Domain
Basic attributes
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set at 2 (X.509v3). | RFC 5280 | INTEGER |
Describes the version of the certificate, the value 2 stands for X.509 version 3. |
serialNumber |
V | A serial number that MUST uniquely identify the certificate within the publishing CA domain. | RFC 5280 | INTEGER |
All end user certificates have to contain at least 8 bytes of unpredictable random data in the certificate’s serial number (serialNumber ). |
signature |
V | MUST be set on the algorithm, as stipulated by the PA. | RFC 5280, ETSI TS 102176 | OBJECT IDENTIFIER |
MUST be the same as the field signatureAlgorithm . For certificates under the G3 root certificate, only sha-256WithRSAEncryption is allowed. |
issuer |
V | MUST contain a Distinguished Name (DN). The field has the following attributes | PKIo, RFC 3739, ETSI TS 102280 | Attributes other than those mentioned below MUST NOT be used. | |
issuer:countryName |
V | See requirement 7.1-pkio174. | ETSI TS 101862, X520, ISO 3166 | PrintableString |
|
issuer:organizationName |
V | See requirement 7.1-pkio174. | ETSI TS 102280 | UTF8String |
|
issuer:serialNumber |
O | See requirement 7.1-pkio174. | RFC 3739 | PrintableString |
|
issuer:commonName |
V | See requirement 7.1-pkio174. | PKIo, RFC 3739 | UTF8String |
The commonName attribute MUST NOT be necessary in order to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739) |
issuer:organizationIdentifier |
V/N | Contains an identification of the issuing TSP. This field MUST be present when the subject:organizationIdentifier is present in the TSP issuing certificate and MUST NOT be present when the subject:organizationIdentifier is NOT present in the TSP issuing certificate. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identification string is specified in paragraph 5.1.4 van ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - 2 character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and - identifier (according to country and identity type reference). |
validity |
V | MUST define the period of validity of the certificate according to RFC 5280. | RFC 5280 | UTCTime |
MUST include the start and end date for validity of the certificate in accordance with the applicable policy laid down in the CPS. |
subject |
V | The attributes that are used to describe the subject (end user) MUST mention the subject in a unique manner and include information about the subscriber. The field has the following attributes | PKIo, RFC 3739, ETSI TS 102 280 | MUST contain a Distinguished Name (DN). Attributes other than those mentioned below MUST NOT be used. | |
subject:countryName |
V | Complete C with two-letter country code in accordance with ISO 3166-1. If an official alpha-2 code is missing, the TSP MAY use the user-assigned code XX. | RFC 3739, X520, ISO 3166, PKIo | PrintableString |
The country code that is used in subject:countryName MUST correspond with the subscriber’s address in accordance with the accepted document or registry. |
subject:commonName |
V | See requirement 7.1-pkio203. | RFC 3739, ETSI TS 102 280, PKIo | UTF8String |
See requirement 7.1-pkio203. |
subject:surname |
V | A correct reproduction of the element of the name laid down in the commonName . Based on the Compulsory Identification Act document. |
RFC 3739 | UTF8String |
This field MUST show the subject’s surname including surname prefixes correctly, as shown on the Compulsory Identification Act document. |
subject:givenName |
V/O | A correct reproduction of the element of the name laid down in the commonName . Based on the Compulsory Identification Act document. |
RFC 3739 | UTF8String |
This field MUST show the subject’s surname including surname prefixes correctly, as shown on the Compulsory Identification Act document. |
subject:organizationName |
V | Full name of the subscriber in accordance with the accepted document or Basic Registry | PKIo | UTF8String |
The subscriber is the entity with which the TSP has entered into an agreement and on behalf of which or pursuant to which the certificate holder acts when using the certificate. In occupational-linked certificates this is equal to the common name of the certificate holder. |
subject:organizationalUnitName |
O | Optional specification of an organizational entity. This attribute MUST NOT include a function indication or similar. | PKIo | This attribute MAY appear several times in organization-linked certificate holders. The field MUST contain a valid name of an organizational entity of the subscriber in accordance with an accepted document or registry In occupational-linked certificate holders, this attribute MUST NOT be incorporated. | |
subject:stateOrProvinceName |
A | The use is advised against. If present, this field MUST contain the province in which the subscriber is established in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the province MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:localityName |
A | The use is advised against. If present, this field MUST contain the location of the subscriber in accordance with an accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the location MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:serialNumber |
V | Number to be determined by the TSP. The combination of commonName , organizationName and serialNumber MUST be unique within the context of the TSP. |
RFC 3739, X 520, PKIo | PrintableString |
The serialNumber is intended to distinguish between subjects with the same commonName and the same organizationName . To avoid susceptibilities a serial number attribute MUST be allocated to every subject. |
subject:title |
V/N | MUST contain value from limitative list of professions in PoR requirement 3.2.5-pkio160. | ETSI TS 102 280, RFC 3739, RFC 5280 | This field SHALL only be used in certificates of the ‘professional certificate’ type. | |
subjectPublicKeyInfo |
V | Contains, among other things, the public key. | ETSI TS 102 280, RFC 3279 | Contains the public key, identifies the algorithm with which the key can be used. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityKeyIdentifier |
V | No | The algorithm to generate the authorityKey MUST be created on an algorithm determined by the PA. |
ETSI TS 102 280, RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
subjectKeyIdentifier |
V | No | The algorithm to generate the subjectKey MUST be created on an algorithm determined by the PA. |
RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the subjectKey (public key of the certificate holder). |
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate. In the PKI for the government, for each certificate type various bits are incorporated in the keyUsage extension. In authenticity certificates the digitalSignature bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In confidentiality certificates, keyEncipherment and dataEncipherment bits MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In certificates for the electronic signature the non-repudiation bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. |
RFC 3739, RFC 5280, ETSI TS 102 280 | BIT STRING |
|
certificatePolicies |
V | No | MUST contain the OID of the Certificate Policy (CP) and the URI of the Certification Practice Statement (CPS), and MAY contain a user notice. The TSP SHOULD use UTF8String in the userNotice field, but MAY use IA5String . ALL certificates issued with their private key residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP+ OID [0.4.0.2042.1.2]; those issued with their private key NOT residing on an SSCD (qualified or not) SHOULD contain the ETSI NCP OID [0.4.0.2042.1.1]. Certificates issued as EU qualified certificates to natural persons with their private key residing in a QSCD, SHOULD contain an additional ETSI QCP-n-qscd OID [0.4.0.194112.1.2], or an additional ETSI QCP-n OID of [0.4.0.194112.1.0] when their private key does not reside on a QSCD. |
RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
An overview of all Certificate Policy OIDs can be found in the document “PKIoverheid registered OIDs”. For the Private Persons domain the OIDs are: - Authenticity: 2.16.528.1.1003.1.2.8.1 - Non-repudiation: 2.16.528.1.1003.1.2.8.2 - Confidentiality: 2.16.528.1.1003.1.2.8.3 Reference to the paragraph numbers of the PoR in the user notice is advised against because the persistency of this cannot be guaranteed (unlike the OID number of the CP). |
subjectAltName |
O | No | Contains one or more alternative names/identification numbers of the certificate holder | RFC 5280, PKIo, ETSI TS 102 280 | Attributes other than those mentioned below MUST NOT be used. | |
subjectAltName:otherName |
O | N/A | See requirement 7.1-pkio202. | PKIo | See description | See description. |
subjectAltName:rfc822Name |
A | N/A | MAY be used for the certificate holder’s e-mail address, for applications that need the e-mail address to be able to function properly. | RFC 5280 | IA5String |
For PKIoverheid certificates in the Government/Companies and Organization domains, the use of e-mail addresses is advised again, because e-mail addresses of certificate holders often change and furthermore are privacy sensitive (spam). If the e-mail address is included in the certificate, the TSP MUST: - have the subscriber sign his/her approval for these and; - check that the e-mail address belongs to the subscriber’s domain, or; - check that the e-mail address belongs to the subscriber (e.g. the professional) and that this person has access to the e-mail address (for example by performing a challenge response). |
basicConstraints |
O | Yes | This field SHALL have its cA sub-field set to its DEFAULT value (FALSE) resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included. |
RFC 5280 | ITU-T Recommendation X.690 (07/2002) on ASN.1 encoding rules states in Section 5.8: “The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value”. Stating in the description that “encoded certificates do NOT include the cA sub-field” therefore is redundant. However, in the past some TSPs employed CA-issuing software which did not do proper ASN.1 encoding resulting in a wrongfully included cA sub-field in encoded certificates. This encoding error resulted in some PKIX software rejecting these certificates. This redundant information therefore has to be regarded as a cautionary hint for TSPs to check their actual certificate encoding for these errors. Chances of this encoding bug still existing in ASN.1 encoding software are however slim since the last mention of such a bug on BugZilla is from 2016. |
|
cRLDistributionPoints |
V | No | MUST include the URI of a CRL distribution point. | RFC 5280, ETSI TS 102 280 | The reference MUST be accessible through the HTTP or LDAP protocol. The attribute reason MUST NOT be used, reference MUST be made to 1 CRL for all types of reasons for revocation. In addition to CRL, other types of certificate status information service MAY be supported. |
|
extKeyUsage |
V | No | RFC 5280 | KeyPurposeId s |
See requirement 7.1-pkio149. |
Private extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityInfoAccess |
O | No | This attribute MUST include the URI of an OCSP responder if Online Certificate Status Protocol (OCSP) plays a role. | This field can optionally be used to reference other additional information about the TSP. | ||
QcStatement |
V/N | No | Certificates for the electronic signature MUST indicate that they are issued as qualified certificates complying with annex I of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qcs-QcCompliance statement in this extension. Certificates for the electronic signature MUST indicate that they are issued as type of certificate complying with annex I of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qct-esign statement in this extension. Certificates for the electronic signature MUST indicate that the private key that is part of the public key in the certificate is saved on a qualified signature creation device (QSCD) complying with annex II of EU regulation 920/2014. This compliance is indicated by including the id-etsi-qcs-QcSSCD statement in this extension. Certificates for the electronic signature MUST contain a reference to the location of the PKI Disclosure Statement (PDS). This URL must present in the id-etsi-qcs-QcPDS statement in
this extension. The certificates for authenticity and the certificates for confidentiality MUST NOT use this extension. |
RFC 3739, ETSI TS 102 280, ETSI TS 101 862 | OBJECT IDENTIFIER |
The aforementioned QcStatement identifiers relate to the following OIDs: - id-etsi-qcs-QcCompliance { id-etsi-qcs 1 } 0.4.0.1862.1.1 - id-etsi-qct-esign { id-etsi-qcs-QcType 1 } 0.4.0.1862.1.6.1 - id-etsi-qcs-QcSSCD { id-etsi-qcs 4 } 0.4.0.1862.1.4 - id-etsi-qcs-QcPDS { id-etsi-qcs 5 } 0.4.0.1862.1.5 |
Profile for certificates under the Server 2020 domain
Basic attributes
Field / Attribute | Criteria | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|
version |
V | MUST be set at 2 (X.509v3). | RFC 5280 | INTEGER |
Describes the version of the certificate, the value 2 stands for X.509 version 3. |
serialNumber |
V | A serial number that MUST uniquely identify the certificate within the publishing CA domain. | RFC 5280 | INTEGER |
All end user certificates have to contain at least 8 bytes of unpredictable random data in the certificates serial number (serialNumber ). |
signature |
V | See requirement 7.1-pkio171. | RFC 5280, ETSI TS 119 312 | OBJECT IDENTIFIER |
|
issuer |
V | MUST contain a Distinguished Name (DN). The field has the following attributes: | PKIo, RFC 3739, ETSI TS 102280 | Attributes other than those mentioned below MUST NOT be used. | |
issuer:countryName |
V | See requirement 7.1-pkio174. | ETSI TS 101862, X520, ISO 3166 | PrintableString |
|
issuer:organizationName |
V | See requirement 7.1-pkio174. | ETSI TS 102280 | UTF8String |
|
issuer:organizationalUnitName |
O | See requirement 7.1-pkio174. | ETSI TS 102280 | UTF8String |
|
issuer:serialNumber |
O | See requirement 7.1-pkio174. | RFC 3739 | PrintableString |
|
issuer:commonName |
V | See requirement 7.1-pkio174. | PKIo, RFC 3739 | UTF8String |
The commonName attribute MUST NOT be needed to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739). |
issuer:organizationIdentifier |
V/N | Contains an identification of the issuing TSP. This field MUST be present when the subject:organizationIdentifier is present in the TSP issuing certificate and MUST NOT be present when the subject:organizationIdentifier is NOT present in the TSP issuing certificate. |
ETSI EN 319 412-1 | UTF8String |
The syntax of the identification string is specified in paragraph 5.1.4 van ETSI EN 319 412-1 and contains: - 3 character legal person identity type reference; - character ISO 3166 [2] country code; - hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and - identifier (according to country and identity type reference). |
validity |
V | MUST define the period of validity of the certificate according to RFC 5280. | RFC 5280 | UTCTime |
MUST include the start and end date for validity of the certificate in accordance with the applicable policy laid down in the CPS. |
subject |
V | The attributes that are used to describe the subject (service) MUST mention the subject in a unique way and include information about the subscriber organization. The field has the following attributes: | PKIo, RFC 3739, ETSI TS 102 280 | MUST contain a Distinguished Name (DN). Attributes other than those mentioned below MUST NOT be used. | |
subject:countryName |
V | Complete C with two-letter country code in accordance with ISO 3166-1. If an official alpha-2 code is missing, the TSP MAY use the user-assigned code XX. | RFC 3739, X520, ISO 3166, PKIo | PrintableString |
The country code that is used in subject:countryName MUST correspond with the subscribers address in accordance with the accepted document or registry. |
subject:commonName |
A | Name that identifies the server. | RFC 3739, ETSI TS 102 280, PKIo | UTF8String |
See requirement 7.1-pkio163 for requirements for the contents of this field. See requirement 3.2.5-pkio170 for validation requirements. |
subject:organizationName |
V | The full name of the subscribers organization in accordance with the accepted document or Basic Registry. | PKIo | UTF8String |
The subscriber organization is the organization with which the TSP has entered into an agreement and on behalf of which the certificate holder (server) communicates or acts. |
subject:stateOrProvinceName |
O | MUST include the province of the subscribers branch, in accordance with the accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the province MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:localityName |
V | MUST include the location of the subscriber, in accordance with the accepted document or Basic registry. | PKIo, RFC 3739 | UTF8String |
Name of the location MUST correspond with the address of the subscriber in accordance with the accepted document or registry. |
subject:serialNumber |
O | The TSP is responsible for safeguarding the uniqueness of the subject (service). The subject:serialNumber MUST be used to identify the subject uniquely. The use of 20 positions is only allowed for OIN and HRN after additional arrangements with Logius. |
RFC 3739, X 520, PKIo | PrintableString |
The number is determined by the TSP and/or the government. The number can differ for each domain and can be used for several applications. |
subjectPublicKeyInfo |
V | Contains, among other things, the public key. | ETSI TS 102 280, RFC 3279 | Contains the public key, identifies the algorithm with which the key can be used. |
Standard extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
signedCertificateTimestampList |
V | No | The Signed Certificate Timestamp List contains one or more Signed Certificate Timestamps. | RFC 6962 | OCTET STRING |
See requirement 4.4.3-pkio154 for the usage of the signedCertificateTimestampList . (OID: 1.3.6.1.4.1.11129.2.4.2) |
authorityKeyIdentifier |
V | No | The algorithm to generate the authorityKey MUST be created on an algorithm determined by the PA. |
ETSI TS 102 280, RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the authorityKey (public key of the TSP/CA). |
subjectKeyIdentifier |
V | No | The algorithm to generate the subjectKey MUST be created on an algorithm determined by the PA. |
RFC 5280 | BIT STRING |
The value MUST contain the SHA-1 hash from the subjectKey (public key of the certificate holder). |
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate. For each certificate type various bits are incorporated in the keyUsage extension. In server certificates the digitalSignature and keyEncipherment bits MUST be incorporated and marked as being essential. Another keyUsage MUST NOT be combined with this. |
RFC 3739, RFC 5280, ETSI TS 102 280 | BIT STRING |
|
certificatePolicies |
V | No | See requirement 7.1-pkio182 for requirements on the contents of this field. | RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
|
subjectAltName |
V | No | Contains one or more alternative identifiers of the subject | RFC 5280, PKIo, ETSI TS 102 280 | Attributes other than those mentioned below MUST NOT be used. | |
subjectAltName:dNSName |
V | Name that identifies the server. | RFC2818, RFC 5280 | IA5String |
See requirement 7.1-pkio163 for requirements for the content of this field. See requirement 3.2.5-pkio170 for validation requirements. |
|
basicConstraints |
O | Yes | This field SHALL have its cA sub-field set to its DEFAULT value (FALSE) resulting in an encoded certificate NOT including the cA sub-field. The optional pathLenConstraint sub-field SHALL NOT be included. |
RFC 5280 | ITU-T Recommendation X.690 (07/2002) on ASN.1 encoding rules states in Section 5.8: “The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value”. Stating in the description that “encoded certificates do NOT include the cA sub-field” therefore is redundant. However, in the past some TSPs employed CA-issuing software which did not do proper ASN.1 encoding resulting in a wrongfully included cA sub-field in encoded certificates. This encoding error resulted in some PKIX software rejecting these certificates. This redundant information therefore has to be regarded as a cautionary hint for TSPs to check their actual certificate encoding for these errors. Chances of this encoding bug still existing in ASN.1 encoding software are however slim since the last mention of such a bug on BugZilla is from 2016. |
|
cRLDistributionPoints |
V | No | MUST include the URI of a CRL distribution point. | RFC 5280, ETSI TS 102 280 | The reference MUST be accessible through the HTTP or LDAP protocol. The attribute reason MUST NOT be used, reference MUST be made to 1 CRL for all types of reasons for revocation. In addition to CRL, other types of certificate status information service MAY be supported. |
|
extKeyUsage |
V | No | extension that indicates for which applications the certificate may be used. | RFC 5280 | KeyPurposeId |
See requirement 7.1-pkio149. |
Private extensions
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
authorityInfoAccess |
V | No | See requirement 7.1-pkio172. |
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
Field / Attribute | Criteria | Critical? | Description | Standard reference | Type | Explanation |
---|---|---|---|---|---|---|
issuer |
V | MUST contain a Distinguished Name (DN). | PKIo | An OCSP Signing certificate MUST be issued under the hierarchy of the PKIoverheid. | ||
keyUsage |
V | Yes | The attribute extension specifies the intended purpose of the key incorporated in the certificate. For each certificate type various bits are incorporated in the keyUsage extension. In OCSP Signing certificates, the digitalSignature bit MUST be incorporated and the extension marked as being critical. The nonRepudiation bit MUST NOT be included. |
RFC 5280, RFC 2560 | BIT STRING |
|
certificatePolicies |
V | No | MUST contain the OID of the PKIoverheid Certificate Policy (CP) as described alongside, the URI of the CPS, and a user notice. The OID scheme is described in the CP - Services. | RFC 3739 | OBJECT IDENTIFIER , UTF8String or IA5String |
The OID for OCSP certificates under the G3 is as follows: - Legacy Organization Person: 2.16.528.1.1003.1.2.5.1 - Legacy Organization Services: 2.16.528.1.1003.1.2.5.4 - Legacy Citizen: 2.16.528.1.1003.1.2.3.1 - 2019 Autonomous Devices: 2.16.528.1.1003.1.2.6.1 - 2023 Organization Person: 2.16.528.1.1003.1.2.5.8 - 2023 Organization Services: 2.16.528.1.1003.1.2.5.8 - 2023 Citizen: 2.16.528.1.1003.1.2.5.8 - 2023 S/MIME: 2.16.528.1.1003.1.2.5.8 The OID for OCSP certificates under the Private Root is as follows: - Private Services/Server: 2.16.528.1.1003.1.2.8.4 - Private Persons: 2.16.528.1.1003.1.2.8.1 |
extKeyUsage |
V | Yes | MUST be used with the value id-kp-OCSPSigning . |
RFC 5280 | ||
ocspNoCheck |
V/O | The CA/B Forum Baseline Requirements require the use of the ocspNoCheck for publicly trusted server certificates. For the other PKIoverheid certificates the use is optional. |
RFC 2560 | The CA/B Forum Baseline Requirements require the use of the ocspNoCheck . It is therefore not clear how browsers are to react on OCSP responder certificates without a ocspNoCheck extension. Browsers will most probably not check the status of an OCSP signing certificate without the extension. |