Programme of Requirements part 1: Introduction v4.10

Table of Contents

Policy Authority

The Policy Authority (PA) of the PKI for the government (PKIoverheid) supports the Minister of the Interior and Kingdom Relations in the management of the PKI for the government.

The government's PKI is an trust framework. This system enables generic and large-scale use of the electronic signature and it also facilitates remote identification and confidential communication.

The tasks of the PA of PKIoverheid are:

• contributing towards the development and the maintenance of the framework of standards that underlies the government's PKI, the Programme of Requirements (PoR);
• supervising and preparing for the process of admittance of Trust Service Providers (TSPs) to the government's PKI;
• regulating and monitoring the activities of TSPs that issue certificates under the root of the government's PKI.

The purpose of the Policy Authority is:

Enforcement of a practicable and trustworthy framework of standards for PKI services that provides an established level of security for the government's communication needs and is transparent to users.

1 Introduction

1.1 Aim of the Programme of Requirements

This is part 1 of the Programme of Requirements (PoR) for the PKI for the government. The purpose of the PoR is to lay down requirements for the use of the governments PKI and to inform the parties involved in the PKI for the government accordingly.

This part introduces the PoR. First of all, in chapter 1 the history of the PKI for the government is described and a short introduction to PKI (Public Key Infrastructure) is provided. Chapter 2 then outlines the design of the PKI for the government, in which the criteria and architecture are dealt with. Chapter 3 describes the requirements that apply within the PKI for the government and how these are positioned within the PKI for the government. The chapter also outlines how the trustworthiness of the services within the PKI for the government is safeguarded and can be verified. Finally, chapter 4 incorporates a summary, providing an explanation on all parts of the PoR.

1.2 History

The Dutch government has high ambitions in the area of electronic services; these are outlined in the "Andere Overheid (Different Government)" programme of action. This specifically expresses the goal that, by 2007 65% of public services have to be offered via the Internet. In late 2007 it was established that this goal had been achieved[1]. An essential condition for electronic services is the trustworthiness of the electronic communication. For example, an electronic grant application generally asks that the identity of the involved parties is established, for a declaration of intent that a public service is actually being requested and for confidentiality regarding the communication between the applicant and the government body providing the grant.

All of the foregoing can be made possible by using generic mechanisms, such as identification and an electronic signature based on Public Key Cryptography. Public Key Cryptography can be used in various ways to ensure trustworthy electronic communication, which is termed a Public Key Infrastructure (PKI). PKI is a very effective basis for the cryptographic part of information security.

Towards the end of 1999, following a decision by the Council of Ministers, the PKIoverheid Task Force was set up. The work of the PKIoverheid Task Force led to a top structure for the PKI for the government being established in 2002[2]. In 2003, the first Trust Service Provider (TSP) joined the PKI for the government and now several organizations are active as TSPs within the PKI for the government.

In 2003, the Policy Authority (PA) of the PKI for the government was established as an offshoot of the PKIoverheid Task Force. The PA manages the PKI for the government top structure and of the framework of standards (Programme of Requirements, PoR) that underlies the PKI for the government. In the PAs Certification Practice Statement (CPS), the activities performed by the PA, in terms of the management of the PKI for the government, are described in detail. This CPS can be found at https://cps.pkioverheid.nl.

[1] See report "Publieke dienstverlening 65% electronisch (65% of all public services electronic)" dated 5 December 2007

[2] Paragraph 2.4 details this top structure, plus the full design of the government's PKI .

1.3 Why PKI

1.3.1 Need for trust

The need for PKI cannot be seen separately from the growing need for electronic communication and services within society in general and the government in particular. There is an increasing demand for transactions to be dealt with electronically. The user does not have to physically visit his transaction partner and, in a user-friendly manner, can perform the transaction from his PC. Furthermore, the recipient of a transaction request can streamline his administrative organization with the new technology and, by doing so, organize his business process more efficiently. This meets the ever increasing demand for high-quality services in the 24-hour economy.

A precondition for a full and completely electronic service is a reliable mechanism that can ensure the same safeguards that currently apply in the "paper" world. This applies to all services, both government services and services within the ordinary economic traffic. Electronic transactions require the identity of the involved parties to be established, the declaration of intent of parties and the confidentiality of the communication between transaction partners.

1.3.2 Opportunities of PKI

The PKI for the government provides communicating parties with safeguards in relation to:

• the identity of a person who purchases a service or the service itself (identification and authenticity);
• the (legal) certainty that a message has been sent by a specific person or a document has been signed by a specific person and that this cannot be denied afterwards (electronic signature, non-repudiation);
• the ability to protect communication against unwanted access (confidentiality, privacy) or amendment (integrity) by third parties.

1.3.3 What is a PKI and how does it work

A PKI is an infrastructure comprising organizational and technical components, within which secure communication is possible. The foundation for PKI is formed by the asymmetric cryptographic algorithms that are used. With this system, the user receives a key pair, comprising a private key which is only known to him and a public key, which is accessible by everyone. A users private and public keys are inextricably tied together. The public key can be distributed (for example in a database, cf. a telephone book); the private key has to be carefully kept secret by the user.

Using these key pairs, secure electronic communication can take place. To apply a digital signature and to achieve confidentiality and authentication, various transactions are performed with the keys.

What is the guarantee that a used key does in fact belong to the sender/recipient? The solution for the linkage between the user and the key pair is achieved by PKI. The user is given a digital identity, a certificate, which states that the public key belongs to him. A certificate is a small file containing the users details, along with his public key. These details are then signed electronically by a Trust Service Provider. Using the certificate, the recipient, also known as the relying party, can check whether the sender is actually who he says he is. The relying party places trust in the TSP that certified the details in the certificate with its electronic signature. You can find a further explanation regarding the operation of PKI at www.logius.nl/pkioverheid.

1.3.4 Opting for PKI

In addition to PKI there are also other mechanisms for establishing identities electronically. Consider the use of passwords, PIN codes and tools that generate one-time codes. However, unlike PKI, these mechanisms do not offer support for confidentiality or the legal equivalence with the handwritten signature. Therefore, when there is a need to communicate information confidentially and/or for an electronic signature to be included that is legally equivalent to the handwritten signature, PKI is the perfect solution.

The support of multiple functions by PKI is often the reason for using PKI to ensure secure communication. PKIoverheid certificates are now used in various processes within the government and the business world. At www.logius.nl/pkioverheid there is an up-to-date list of organizations that act as TSPs with the PKI for the government.

1.4 Status

This is version 4.8 of part 1 of the Programme of Requirements. The current version has been updated up to February 3, 2020, inclusive.

All parts of the PoR are version controlled. Change requests are dealt with in accordance with the procedure described in the document "Procedurebeschrijving wijzigingen in PvE (Procedural description amendments in PoR)". This document can be consulted at the following website www.logius.nl/pkioverheid.

1.5 Normative references

The standards, legislation and regulations referred to in this document are as follows:

1. Uitvoering EU-verordening elektronische identiteiten en vertrouwensdiensten (Execution EU regulation electronic identification and trust services)

   Act dated 21 december 2016 amending Book 3 and Book 6 of the Civil Code, the Telecommunications Act, the General Administrative Law Act and related changes in other acts concerning the implementation of EU regulation on electronic identification and trust services.

2. Besluit Vertrouwensdiensten (Trust Services Decree)
   Decree dated 22 February 2017, establishing the requirements for providing trust services, repealing the Electronic Signatures Decree and amending several other decrees.

3. Regeling Vertrouwensdiensten (Trust Services Regulation)
   Regulation of the Minister for Economic Affairs of 24 February 2017, nr. WJZ/17028856, in conjunction with the Minister of Finance and the Minister of Infrastructure and the Environment, establishing procedural requirements regarding the application to certifying body of qualified devices, the application to adjudication of the qualified status and regarding the trust list, repealing the Electronic Signatures Regulation and the Trust List Regulation and the modification of a number of regulations as a result of the entry into force of the eIDAS regulation.

4. eIDAS regulation
   Regulation (EU) No 910/2014 of the European parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC.

5. ETSI EN 319 411-2,“Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 2: Requirements for trust service providers issuing EU qualified certificates”.

   This European standard contains the requirements for TSPs that issue qualified certificates for electronic signatures to the public. Within the PKI for the government, this standard is laid down for all of its TSPs that issue personal certificates.

6. ETSI EN 319 411-1, ” Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements “.

   This Technical Specification contains the requirements for TSPs that issue public key certificates to the public. Within the PKI for the government, this standard is specifically laid down for TSPs that issue non-personal certificates.

7. ETSI EN 319 403 Trust Service Provider Conformity Assessment - Requirements for conformity assessment bodies assessing Trust Service Providers

8. EN 45012:1998, General requirements for bodies operating assessment and certification/registration of quality systems.

9. “Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures”, CEN/ISSS WS/E-Sign (CWA 14167-1).

   This is an elaboration of the requirements for systems of Trust Service Providers, as listed in Appendix II (sub f) of European Directive 1999/93/EC.

10. ETSI TS 119 312, “Electronic Signatures and Infrastructures (ESI); Cryptographic Suites”.

    This document describes which algorithms and key lengths are allowed within the PKI for the government.

11. “Security Requirements For Cryptographic Modules”, NIST (FIPSPUB140‑2).

    This outlines the requirements of the American government for cryptographic products.

12. “Secure Electronic Signature Devices, Version EAL 4+”, CEN/ISSS WS/E-Sign (CWA14169).

    This outlines the requirements for the secure tool for creating electronic signatures, as mentioned in Appendix III of the guideline.

13. “EESSI Conformity Assessment Guidance - Part 2: Certification Authority services and processes”, CEN/ISSS WS/E-Sign (CWA 14172-2).

    This provides clarification of the requirements for Trust Service Providers.

14. “Cryptographic module for TSP Signing Operations” – Protection Profile CEN/ISSS WS/E-Sign (CWA 14167-2).

    This outlines the requirements for the cryptographic product specifically used by a Trust Service Provider.

15. “EESSI Conformity Assessment Guidance – Part 3: Trustworthy systems managing certificates for electronic signatures”, CEN/ISSS WS/E-Sign (CWA 14172-3).

    This provides clarification of the requirements for the systems used by a Trust Service Provider.

16. “Cryptographic module for TSP Signing Operations” – Protection Profile CEN/ISSS WS/E-Sign (CWA 14167-4).

    This outlines the requirements for the cryptographic product specifically used by a Trust Service Provider.

17. EN 419 211 “Application Interface for Secure Elements for Electronic Identification, Authentication and Trusted Services”
    This outlines the requirements for the cryptographic product specifically used by a Trust Service Provider.

2 Overview of the PKI for the government

2.1 Introduction

This chapter first covers the strategic criteria that underlie the PKI for the government. It then deals with the certificate model that is used and finally an explanation is given about the design of the PKI for the government.

2.2 Strategic criteria

To execute PKI services within the PKI for the government, the following strategic criteria apply:

• Workable infrastructure. The PKI for the government facilitates the communication between government and government, between government and businesses, between businesses and businesses and between the government and citizen (communication domains).

• One established trust level. The trust level of the PKI for the government is based on the Electronic Signatures Act and international standards. This enables users to use the governments electronic services with one type of signature, which has the same legal consequences as a handwritten signature.

• Organizational interoperability. High demands are made on organizations that wish to issue certificates within the PKI for the government with regard to registering, producing, issuing, managing and monitoring certificates and key pairs. These demands are incorporated in the Certificate Policy (CP) [1] , which is part of the PoR (part 3). These demands are placed on all parties within the PKI for the government.

• Technical interoperability. The PKI for the government is based on open standards by means of which interoperability is achieved. This enables various suppliers to offer products within the PKI for the government and means process owners are not dependent on one provider.

• Certificates for roles. Within the PKI for the government, certificates are issued in a number of domains, which are the Government/Companies, Organization, Citizen and Autonomous Devices domain. In the Government/Companies and Organization domains, certificates are issued to entities that are attached to an organization, or that act under a recognized profession. In the Citizen domain, certificates are issued to individuals. This provides transparency about the role that a person fulfils in the electronic communication. In the Autonomous Devices domain, certificates are issued to devices that, during their operational lives, independently safeguard the integrity and authenticity of (measurement) data for (a specific objective within a core task of) a specific government agency.

• The central part of the PKI for the government is the determinative factor for trust. The trustworthiness of the PKI for the government is determined by the trustworthiness of the central part. The PAs Certification Practice Statement describes which procedures and measures the PA has taken to safeguard the security of the central part.

[1] A CP describes the requirements laid down for the issuance and use of a specific type of certificate.

By contrast, a Certification Practice Statement (CPS) describes how a TSP meets these requirements. The CPs are compiled by the PA and apply to all TSPs in a domain. By contrast, the CPS is compiled by every individual TSP.

2.3 Certificate model

The certificate plays a key role within a PKI (also see paragraph 1.3). That is because the certificate enables the certificate holder to obtain a digital identity. Within the PKI for the government, a distinction is made between certificates for people, certificates for services (for example systems and applications), Extended Validation SSL certificates and certificates for Autonomous Devices. In the paragraphs below, an explanation is given about the certificate model that is used within the PKI for the government.

2.3.1 Personal certificates

Certificates for individuals are linked to the person (or linked to the identity). People in different capacities can obtain different certificates: as a citizen, as an employee of a government organization or company or working in a recognized profession. The PKI for the government uses three separate certificates and keys for the electronic signature, authenticity and confidentiality. This is also known as the 3-certificate model.

The electronic signature certificate fulfils the legal requirements published in the European Directive 1999/93/EC and outlined in Dutch legislation[1], of a signature relating to electronic data, in the same way as a handwritten signature.

The authenticity certificate is suitable for reliable electronic identification and authentication of people.

The confidentiality certificates that are issued within the PKI for the government are suitable for protecting the confidentiality of data that is interchanged electronically.

The authentication and confidentiality certificates have the same trust level as the qualified certificate. This means that the requirements laid down in respect of the electronic signature certificate also apply to the authenticity certificate and the confidentiality certificate.

[1] This concerns the Electronic Signatures Act and Decree and corresponding Regulations.

2.3.2 Services certificates

The services certificate is a certificate that is not linked to a specific person. This kind of certificate applies when the certificate holder is a device or a system (a non-natural person), operated by or on behalf of an organizational entity. But this also applies when a certificate, under the responsibility of an organizational entity, is not linked to one certificate holder. An example of this is a certificate that is linked to a position (job); when an employee leaves, a different person will take over the job, and the certificate can be given to this person.

The PKI for the government uses three separate services certificates and keys, which are an authenticity certificate, a confidentiality certificate and a server certificate. The authenticity and confidentiality certificates can be used in both of the categories described above. The server certificate only belongs to the first category (device or system). With services certificates it is particularly important that certainty is provided about the connection between the device, the system or the position and the organization listed in the certificate.

The three types of services certificates have the same security level. This security level is based on the level of the personal certificates.

2.3.3 Extended Validation (EV) SSL certificates

EV SSL certificates are non-personal certificates. These can be used to secure a connection, through the TLS/SSL protocol, between a specific client and a server that belongs to the organizational entity listed as subscriber in the relevant certificate.

One of the main properties of an EV SSL certificate is that this colours the address bar of the browser green. This means that the identity of the websites owner, which is given in the SSL certificate, is validated based on the extremely strict EV guidelines. However, this functionality was deprecated in all browsers by the end of 2019.

2.3.4 Autonomous device certificates

The autonomous device certificate is a non-personal certificate that is issued in the Autonomous Devices domain. This kind of certificate applies when the certificate holder is a device, where the operation and the method of production is demonstrable in accordance with the framework of standards of the specific type of autonomous devices and that, in that capacity, is authorized by the framework author to use the autonomous device certificate linked to (for example, the serial number of) that device.

The PKI for the government uses three separate autonomous devices certificates and keys, which are an authenticity certificate, a confidentiality certificate and a combination certificate.

Authenticity certificates can be used for the electronic identification and authentication of the Autonomous Device and its certified operation. Confidentiality certificates can be used to protect the confidentiality of data that is exchanged using the Autonomous Device and/or that is stored within that device in an electronic format. Combination certificates can be used to secure a connection between a specific client and an Autonomous Device.

2.4 Design of the PKI for the government

The governments Public Key Infrastructure (PKI) has a structure where a central and an operational or local part of PKIoverheid are defined. Within the PKI for the government three types of root certificate can be distinguished:

• the regular root;
• the extended validation root, and;
• the private root.

The G3 (SHA-256) contains the following domains:

• Organization Person

• Citizen

• Organization Services

• Autonomous Devices

The EV root contains a structure or root (Staat der Nederlanden (State of the Netherlands) EV Root CA) for the issuance of PKIoverheid EV SSL certificates, including 1 EV intermediary CA based on the SHA-256 algorithm. However, this intermediary CA was revoked on September 10, 2020 (including underlying issuing CAs), and replaced by a new OV-only (Organisation Validation) intermediary certificate.

Finally PKIoverheid has a private root based on the SHA-256 algorithme which issues non-publically trusted certificates. The Private root contains the following domains:

• Private services

• Private persons

2.4.1 Description of the structure State of the Netherlands Root CA

Within the central part of the structure of the State of the Netherlands Root CA structure a number of actors are distinguished. These actors are:

1. the Government (Ov)-PA, responsible at the highest level for laying down the policy and general standards that apply within the structure of the State of the Netherlands Root CA G1 and G2 and the issue of certificates;

2. the Ov-CA, concerns a technical component that produces the highest (or Root) certificate within the structure of the State of the Netherlands Root CA G1 and G2 and produces certificates for the underlying domain CAs;

3. the Domain (D)-PA, that is responsible for the domain-specific content of the Ov-PA standards, and determines the conditions of the issue of certificates within a domain;

4. the D-CA, concerns a technical component that performs the actual production of certificates for the TSPs.

The coordinating government level and the domain level form the PKIs policy structure. Within these levels, policy and standards are laid down and the regulation is organized.

The TSP level is the operational or local part of the State of the Netherlands Root CA G1 and G2 structure, where the direct interaction with the users takes place. At TSP level, the TSP organization is ultimately responsible for issuing certificates.

The TSP level is the operational level where the direct interaction with the users of the State of the Netherlands Root CA G1 and G2 structure takes place. At TSP level, the TSP organization is ultimately responsible for issuing certificates. The certificates of the TSPs are generated by the CAs domain. Further details are shown in figure 1 below. This figure also shows the certificates from the central infrastructure, which are the root certificate (1), the domain certificates (2) and the TSP certificates (3). As shown in the figure, the Policy Authority CPS describes the procedures followed by the PA when issuing and managing the certificates from the central infrastructure. In the following paragraphs, the various levels and components are described in more detail.

2.4.2 Coordinating Government level and Domain level

Maintenance of the entire agreements system and organization of the required supervision are tasks and responsibilities referred to in PKI terms as the PA (Policy Authority). The PA of PKIoverheid has a number of roles within the State of the Netherlands Root CA structure; a few of the important roles are mentioned below:

• to maintain the framework of standards (PoR), which lists the requirements for each domain;
• identifying consequences for and required adaptations of legislation and regulations;
• maintaining the central part of the State of the Netherlands Root CA G1 and G2 structure and making sure that parties are included within the hierarchy of the State of the Netherlands Root CA structure;
• enforcing the supervision of the hierarchy (TSPs);
• making preparations in relation to admitting TSPs to the State of the Netherlands Root CA structure;
• executing the admission of TSPs including creation, issue and maintenance of TSP certificates;
• regular publication of the State of the Netherlands Root CA G1 and G2 and domain CRLs;
• following the international standardisation developments and, if necessary, taking the initiative in relation to these developments, as well as synchronising these with developments in respect of the PKI of foreign governments.

Figure 1

2.4.3 Description of the structure State of the Netherlands EV Root CA

The structure of the State of the Netherlands EV Root CA largely corresponds with the structure of the State of the Netherlands Root CA G2 and G3.

Within the central part of the structure of the State of the Netherlands EV CA a number of actors are distinguished. These actors are:

1. the Government (Ov)-PA, responsible at the highest level for laying down the policy and general standards that apply within the structure of the State of the Netherlands EV Root CA and the issue of certificates;

2. the Ov-CA, concerns a technical component that produces the highest (or Root) certificate within the State of the Netherlands EV CA and produces certificates for the underlying domain CAs;

3. the intermediary I-CA, concerns a technical component that actually produces certificates for the TSPs.

The coordination government level forms the policy structure of the State of the Netherlands EV Root CA structure. Within this level, policy and standards are laid down and the regulation is organized.

The TSP level is the operational or local part within the State of the Netherlands Root CA structure, where the direct interaction with the users takes place. At TSP level, the TSP organization is ultimately responsible for issuing EV SSL certificates.

The TSP level is the operational level where the direct interaction with the users takes place. At TSP level, the TSP organization is ultimately responsible for issuing EV SSL certificates. The certificates of the TSPs are generated by the State of the Netherlands EV Intermediary CA. Further details are provided in figure 2 below. This figure also shows the certificates in the central infrastructure, which are the State of the Netherlands EV Root CA (1), the State of the Netherlands EV Intermediary CA certificate (2) and the EV TSP certificates (3). As shown in the figure, the CPS Policy Authority describes the procedures that are used by the PA when issuing and managing the EV certificates from the central infrastructure. In the following paragraphs, the various levels and components are described in more detail.

2.4.4 Coordinating Government and Intermediate level

Maintenance of the entire agreements system and organization of the required regulation are tasks and responsibilities referred to in PKI terms as the PA (Policy Authority). The PA PKIoverheid has a number of tasks within the State of the Netherlands EV Root CA; a few of the important tasks are mentioned below:

• maintaining the framework of standards PoR part 3f;
• identifying consequences for and required adaptations of legislation and regulations;
• maintaining the central part of the State of the Netherlands EV Root CA structure and making sure that parties are included within the hierarchy of the State of the Netherlands EV Root CA structure;
• enforcing the supervision of the hierarchy (TSPs);
• making preparations in relation to admitting TSPs to the State of the Netherlands EV Root CA structure;
• implementation of the admission of TSPs including creation, issue and maintenance of EV TSP CA certificates;
• regular publication of the State of the Netherlands EV Root CA and the State of the Netherlands EV Intermediary CA CRLs;
• following the international standardisation developments and, if necessary, taking the initiative in relation to these developments, as well as coordinating with developments in respect of the PKI of foreign governments.

Figure 2

2.4.5 Operational level

TSP level

Below the central infrastructure is the layer where, in terms of the European Directive and the Dutch Law, the Trust Service Provider (TSP) resides. The TSP is responsible for issuing certificates to end users, both in the form of natural persons and other end entities. The organization that performs the TSP function is included in the certificate in the "issuer" field. Several TSPs are active within the PKI for the government based on the requirements laid down by the PA.

RA

The RA is a sub-activity that falls under the responsibility of the TSP. In the RA process, the identity of the applicant for a certificate is verified before the certificate is issued. The RA process consists of the registration of the request, the verification of the identity of the applicant and the issuance of the certificate. The RA has a clear relationship with one or more CAs (for example, for the various types of certificates): The RA instructs the CAs to produce certificates.

CA

The CA is a sub-activity that is performed under the responsibility of the TSP. After registration and successful verification, the certificate has to be produced. The RA instructs the CA to produce this certificate.

3 Trustworthiness of the services

3.1 Positioning of the PKI for the government requirements

3.1.1 TSP services

The requirements laid down by the PKI for the government relate to the services of TSPs within the PKI for the government. These requirements are based on:

1. (inter)national legislation;

2. international standards, and;

3. PKIoverheid requirements.

The positioning of the requirements within the PKI for the government is as follows:

• The primary principle as far as the requirements that have to be fulfilled within the PKI for the government (by TSPs) isEU Regulation 910/2014 (eIDAS).

• Under the auspices of the ETSI, in an international context a detailed system has been created of standards with substantive demands for TSPs that issue qualified certificates. The requirements under these standards provide further specifications for articles under the legal framework. This mainly concerns requirements from the standard ETSI EN 319 411-2 which lists requirements for TSPs that issue qualified certificates, ETSI EN 319 411-1 which contains requirements for the issuance of non-qualified certificates, server and/or EV SSL certificates.

• A number of points in the requirements formulated under A. and B. are not sufficiently specific as far as the PKI for the government is concerned. That is why these requirements have been specified further. TSPs that wish to issue PKIoverheid certificates therefore also have to fulfil these requirements.

Although the ETSI EN 319 411-1 and EN 319 411-2 standards and the PKIo requirements have been specifically developed for the qualified certificate, based on the principle of one security level for all certificates, within the State of the Netherlands Root CA G1 and G2 structure, it has been decided to also declare this security level applicable to the personal confidentiality certificate and the authenticity certificate.

3.2 Establishing trustworthiness

3.2.1 Admittance and regulation

To safeguard the trustworthiness of the PKI for the government, TSPs within the PKI for the government have to be reliable organizations that fulfil high requirements in respect of their operational procedures, technical devices, security of information, expertise and reliability of staff and the provision of information to their target group. The specific requirements which a TSP has to fulfil in order to be able to issue certificates within the PKI for the government are listed in part 3 of the PoR.

To establish whether the TSP meets the stipulated requirements and all formalities, a formal admittance procedure has to be followed. This procedure describes the proof of conformity that has to be supplied and which quality criteria apply to the executive audit organizations, following previously developed, generally accepted standards and certification schemes.

To be able to continue to safeguard the trustworthiness of the PKI for the government, including after the admittance to the PKI for the government, the TSPs have to continue to fulfil the requirements stipulated in part 3. To determine this, the PA supervises the TSPs that have entered. Furthermore, the TSPs have to regularly supply proof of conformity.

The entire admittance procedure and the way in which the PA supervises is described in PoR part 2 "Admittance to and Supervision within the PKI for the government".

3.2.2 Trust chain

To enable relying parties to rely on an end user certificate, a number of checks have to be performed, walking the so-called 'chain of trust'.

Figure 3

A relying party has a certificate from someone else (the certificate holder) and wants certainty in respect of the trustworthiness of this certificate. A certificate is verified by performing the following checks [1] :

• Has the message been changed whilst being sent, or is the integrity safeguarded?
• Has the certificate that has been used been revoked and included on a so-called "black list"?
• Is the certificate still valid?

The software then establishes whether the certificate has been issued by a trusted party. To be able to perform this latter check, the software has to have the State of the Netherlands Root CA G1 and/or G2 or the State of the Netherlands EV Root CA root certificate of the PKI for the government. If the root certificate is not available, the user receives an error message. That is why the PA has decided to include the root certificate in frequently used operating systems and Open Source browsers.

When software is used in which the root certificate is not included, as is the case with the Private root of PKIoverheid, the relying party can securely download the root certificate at https://cert.pkioverheid.nl.

The TSP certificate is issued by the PA and can be checked using the domain/intermediary certificate. This latter certificate is also issued by the PA and can be checked using the root certificate. At each level of the PKI for the government, the trust in a certificate therefore depends on the trust placed in the party that has issued the certificate. From the relying parties point of view, in the first verification step that is the TSP, in the second step the PA at the level of the domains or the Intermediary certificate and finally the PA at the highest level of the hierarchy. The root certificate is therefore the anchor point of trust in the hierarchy of the PKI for the government and establishes the trust that is placed in all other certificates that are issued within the State of the Netherlands CA G1 and G2 or the State of the Netherlands EV Root CA structure. By expressing trust in the root certificate, all underlying domain or intermediary, TSP and end user certificates are trusted. The users only have to trust one certificate. An important aspect is determining the trustworthiness of the entity that issued the certificate.

[1] These checks are usually performed automatically by the application that is used. The aforementioned checks have to be performed for every certificate in the chain of reliance.

3.2.3 Trustworthiness of the entity issuing the certificate

To be able to speak of a trustworthy hierarchy, it is extremely important that the PA functions in a trustworthy manner. The PA safeguards the trustworthiness of the root certificates and the domain certificates and the Intermediary certificate by applying adequate security measures. These security measures, as well as the way in which the PA supervises the TSPs, are described in the CPS of the PA. By assessing the CPS of the PA, the relying party can establish whether they trust a certificate that is issued within the PKIoverheid structure. The hierarchical structure enables a relying party avoiding having to assess in detail every CPS of the TSPs within the PKI for the government. Finally, the trustworthy functioning of the PA has to be established frequently by having an audit performed by external auditors.

4 Summary of the Programme of Requirements

The diagram below shows the structure of the PoR, followed by a short explanation of each part.

Figure 4: Structure of the Programme of Requirements

Part 1: Introduction to the Programme of Requirements

Part 1 provides an introduction to the PoR and the PKI for the government in general. It also outlines how the applicable requirements are set out within the PKI for the government. Mainly aimed at relying parties, certificate holders and process owners, this part provides important information to gain an understanding of the PKI for the government and corresponding standards system, without a profound knowledge of PKI being required.

Part 2: Admittance to and regulation within the PKI for the government.

The PoR lays down requirements which TSPs have to fulfil. Part 2 describes how a TSP can join the PKI for the government, can demonstrate compliance with the requirements and which formalities have to be met. It also describes how the PA supervises the TSPs that have joined.

Part 3: Certificate Policies

Part three of the Programme of Requirements of the PKI for the government consists of the following elements:

• Part 3 Basic requirements. The basic requirements are applicable to all Certificate Policies in part 3 of the Programme of Requirements;
• Part 3 Additional requirements. This contains all additional requirements that are applicable to one or more CPs, but not all CPs;
• Part 3 Reference matrix PKI for the government and ETSI. An overview of PKI for the government requirements in reference to the ETSI requirements of which it is complementary, and;
• Part 3a through j: the Certificate Policies of the different PKI for the government certificates. These are the CPs for the issuance of end-entity certificates under the regular root, private root and EV root. These root certificates all have multiple versions or generations.

The CPs in part 3 of the PoR are constructed as follows:

• Part 3a: personal certificates in the domain Organization

• Part 3b: services authenticity and confidentiality certificates in the domain Organization

• Part 3c: personal certificates in the domain Citizen

• Part 3d: services certificates in the domain Autonomous Devices

• Part 3e: website and server certificates in the domain Organization

• Part 3f: Extended Validation certificates under the EV root certificate

• Part 3g: services authenticity and confidentiality certificates in the domain Private services

• Part 3h: server certificates in the domain Private services

• Part 3i: personal certificates in the domain Private persons

• Part 3j: Organisation Validation certificates under the public EV root

It is possible to issue multiple types of certificates under a Certificate Policy. This is clearly stated in the applicable CP. Part 3a for instance differentiates between authenticity, confidentiality and non-repudiation certificates. Each CP contains an appendix containing the certificate profile.

Part 4: Definitions and abbreviations

The definitions and abbreviations used in the PoR are explained in part 4.

5 Revisions

5.1 Version 1.0

First version.

5.2 Version 1.0 to 1.1

New

None

Modifications

None

Editorial

None

5.3 Version 1.1 to 1.2

New

• The following paragraphs are new in connection with the creation of the State of the Netherlands Root CA - G2 within the government's PKI:

  • Paragraph 2.4.

Modifications

• Paragraph 2.2;
• Paragraph 2.4.2;
• Chapter 4.

Editorial

• Only a few editorial changes have been made but these do not affect the content of the information.

5.4 Version 1.2 to 2.0

New

• The following paragraphs are new in connection with the introduction of the Autonomous Devices Domain within the government's PKI:

  • Paragraph 2.3.3.

Modifications

• The following paragraphs have been modified in connection with the introduction of the Autonomous Devices Domain within the government's PKI:

  • Paragraph 2.3;
  • Paragraph 2.5.1;
  • Chapter 3.

Editorial

• Only a few editorial changes have been made but these do not affect the content of the information.

5.5 Version 2.0 to 2.1

New

None

Modifications

None

Editorial

• Only a few editorial changes have been made but these do not affect the content of the information.

5.5 Version 2.1 to 3.0

New

• The following paragraphs are new in connection with the introduction of Extended Validation within the PKI for the government:

  • Paragraph 2.3.3;
  • Paragraph 2.4.3;
  • Paragraph 2.4.4.

Modifications

• The following paragraphs have been modified in connection with the introduction of Extended Validation within the PKI for the government:

  • Paragraph 1.5;
  • Paragraph 2.3;
  • Paragraphs 2.4, 2.4.1 to 2.4.2;
  • Paragraph 3.1.1;
  • Paragraph 3.2.2;
  • Chapter 4.

Editorial

• A number of editorial changes have been made but these do not affect the content of the information.

5.6 Version 3.5 to 3.6

New

None.

Modifications

• Changes caused by the introduction of the G3 root certificate and certification against ETSI EN 319 411-2 within the PKI for the government.

Editorial

None.

5.7 Version 3.6 to 3.7

New

None.

Modifications

None.

Editorial

• Reference to version 9.2 of the TTP.NL scheme

5.8 Version 3.7 to 4.0

New

None.

Modifications

None.

Editorial

• Reference to the private root and the new layout of PoR part 3.

5.9 Version 4.0 to 4.1

New

None.

Modifications

• Changed the normative reference from ETSI EN 319 411-3 to ETSI TS 102 042.

Editorial

None.

5.10 Version 4.2 to 4.3

New

None.

Modifications

• ETSI TS 102 042 replaced by ETSI EN 319 411-1 (effective date 1-7-2016);
• ETSI TS 102 176-1 replaced by ETSI TS 119 312 (effective date 1-7-2016);
• Removed references to G1 Root (Root CA in question has expired);
• Updated a number of illustrations;
• Corrections for PoR parts (wrong references).

Editorial

None.

5.11 Version 4.3 to 4.4

New

None.

Modifications

None.

Editorial

• Updated reference (URL) to CPS;
• Replaced term CPS (Certification Service Provider) with TSP (Trust Service Provider) in light of eIDAS directive.

5.12 Version 4.4 to 4.5

New

None.

Modifications

• Modified normative references as a result of the repealing of the Electronic Signature Act and the modification of different acts and the introduction of the eIDAS regulation.

Editorial

None.

5.13 Version 4.6 to 4.7

New

None.

Modifications

• EN 419 211 added. This outlines the requirements for the cryptographic product specifically used by a certification service provider (effective date immediately after publication PoR 4.7).

Editorial

None.

5.14 Version 4.7 to 4.8

New

None.

Modifications

• Added reference to part 3j;
• Added changes due to revocation of EV intermediate certificate.

Editorial

None.

5.15 Version 4.8 to 4.9

New

None.

Modifications

None.

Editorial

None.

Deletions

None.

5.16 Version 4.9 to 4.10 (part 1)

New

None.

Modifications

None.

Removals

None.

Editorial

None.