Programme of Requirements part 3a: Certificate Policy for certificates in Organization Person (G3) Domain v4.7

Table of Contents

1 Introduction to the Certificate Policy

1.1 Overview

This is part 3a of the Programme of Requirements (PoR) of the PKI for the government and is called the Certificate Policy (CP). Set out in the PoR are the standards for the PKI for the government. This section relates to the requirements laid down for the services of a Certification Service Provider (TSP) within the PKI for the government. Within the PKI for the government , a distinction is made between various domains. This document only relates to the personal certificates issued by TSPs in the Government/Companies and Organization domains.

This chapter includes a brief explanation of the CP. A more detailed explanation regarding the background and structure of the PKI for the government, as well as the cohesion between the various parts within the PoR is included in part 1 of the PoR.

For a list of the definitions and abbreviations used in this section, please refer to part 4 of the PoR.

1.1.1 Design of the Certificate Policy

As stated in part 1 of the PoR, the requirements that form part of the CP consist of requirements [1]:

• that ensue from the Dutch legal framework in relation to the electronic signature;
• that ensue from the latest version of the ETSI EN 319 411-2 standard, QCP-n-qscd (ETSI CP OID 0.4.0.194112.1.2) for non-repudiation certificates;
• that ensue from the latest version of the ETSI EN 319 411-1standard, where policy NCP+ is applicable to authenticity and encryption certificates.;
• that are specifically drawn up by and for the PKIoverheid.

Incorporated in chapters 2 to 9 inclusive are references to the specific PKIoverheid requirements in the Additional Requirements. The table below shows the structure of the reference to the actual PKIoverheid requirement (PKIo requirement).

This CP also includes a number of provisions that are not formulated as PKIo requirements. These provisions do not make any demands on the TSPs within the PKI for the government, but do apply as a policy to the PKI for the government. This concerns provisions from paragraphs 1.1, 1.1.1, 1.1.2, 1.2, 1.3, 1.4, 1.5, 8, 9.12.1, 9.12.2, 9.14 and 9.17.

The profiles used within PKIoverheid relating to the end user certificates are listed in appendix A. The certificate status information is listed in the basic requirements.

[1]: For an explanation regarding the positioning of the requirements applicable within the PKI for the government, please refer to part 1 of the PoR.

[2]: Chapters 2 to 9 inclusive only include those paragraphs from RFC 3647 to which a PKIo requirement applies.

1.1.2 Status

This is version 4.7 of part 3a of the Programme of Requirements. The current version has been updated up to and including 1 February 2019.

The PA has devoted the utmost attention and care to the data and information incorporated in this CP. Nevertheless, it is possible that there are inaccuracies and imperfections. The PA accepts no liability for damage resulting from these inaccuracies or imperfections, nor is any liability assumed for damage caused by the use or distribution of this CP, if this CP is used for purposes other than for the use of certificates described in paragraph 1.4 of this CP.

1.2 References to this CP

Within the PKI for the government different structures or roots are used based on the SHA-256 algorithm (G2 and G3). Furthermore these structures are devided into different domains.

The G2 root is devided into an Organization, a Citizen and a Autonomous Devices domain.

Under the G3 root there are domains for Organization Person, Organization Services, Citizen, and Autonomous Devices.

Each CP is uniquely identified by an OID, in accordance with the following schedule.

The OID is structured as follows: {joint-iso-itu-t (2). country (16). the Netherlands (528). Dutch organization (1). Dutch government (1003). PKI for the government(1). CP (2). Organization Domain (5). authenticity (1)/non repudiation (2)/confidentiality (3). version number}.

If requirements only apply to one or two types of certificates, this is expressly specified by stating the Object Identifier (OID) referencing the applicable CP or CPs.

1.3 User Community

Within the Government/Companies Organization and Organization Person domains, the user community consists of subscribers who are organizational entities within the government and business community (see PKIo 3.2.2-pkio14) and of certificate holders, who also belong to these subscribers. There are also individuals working in a recognized profession who are both subscriber and certificate holder. In addition there are relying parties, who act with a reliance on certificates of the relevant certificate holders.

The parties within the user community are subscribers, certificate holders and relying parties.

• A subscriber is a natural or legal personality who enters into an agreement with a TSP on behalf of one or more certificate holders for the certification of public keys. A subscriber can also be a certificate holder.
• A certificate holder is an entity, characterized in a certificate as the holder of the private key that is linked to the public key provided in the certificate. The certificate holder is either a part of an organizational entity for which a subscriber is the contracting party (organization-linked certificate holder), or the practitioner of a recognized occupation and, in that capacity, is a subscriber and therefore the contracting party (profession-linked certificate holder).
• A relying party is every natural or legal personality who is a recipient of a certificate and who acts with a reliance on that certificate.

1.4 Certificate Usage

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

[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. More information can be obtained in appendix A of the base requirements.

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

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

1.5 Contact information Policy Authority

The PA is responsible for this CP. Questions relating to this CP can be put to the PA; the address can be found at: http://www.logius.nl/pkioverheid.

2 Publication and Repository Responsibilities

2.1 Electronic Repository

Contains no additional requirements

2.2 Publication of TSP Information

3 Identification and Authentication

3.1 Naming

3.2 Initial Identity Validation

3.3 Identification and Authentication for Re-key Requests

Contains no additional requirements

4 Certificate Life-Cycle Operational Requirements

4.1 Certificate Application

Contains no additional requirements

4.2 Certificate Acceptance

Contains no additional requirements

4.3 Key Pair and Certificate Usage

Contains no additional requirements

4.4 Certificate Revocation and Suspension

4.5 Certificate Status Services

Contains no additional requirements.

5 Facility, Management and Operational Controls

5.1 Procedural Controls

Contains no additional requirements.

5.2 Personnel Controls

Contains no additional requirements.

5.3 Audit Logging Procedures

5.4 Records Archival

5.5 Compromise and Disaster Recovery

6 Technical Security Controls

6.1 Key Pair Generation and Installation

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.3 Other Aspects of Key Pair Management

6.4 Activation data

6.5 Computer Security Controls

Contains no additional requirements

6.6 Life Cycle Technical Controls

Contains no additional requirements.

6.7 Network Security Controls

Contains no additional requirements.

7 Certificate, CRL and OSCP profiles

7.1 Certificate Profile

7.2 CRL Profile

Contains no additional requirements.

7.3 OCSP Profile

8 Compliance Audit and Other Assessments

All subjects relating to the conformity assessment of the TSPs within the PKI for the government are covered in PoR part 2 and the basic requirements.

9 Other Business and Legal Matters

9.1 Financial Responsibility

9.2 Intellectual Property Rights

Contains no additional requirements.

9.3 Representations and Warranties

9.4 Limitations of Liability

9.5 Amendments

Contains no additional requirements.

9.6 Dispute Resolution Provisions

Contains no additional requirements.

9.7 Governing Law

Contains no additional requirements.

9.8 Other provisions

If by judicial decision one or more provisions of this CP are declared to be invalid or not applicable, this does not affect the validity and applicability of all other provisions.

10 Appendix A Profiles certificates

Profile of the certificate for the Organization and Organization Person domains

10.1 Criteria

When defining the fields and attributes within a certificate, the following codes are used:

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

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

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

10.2 Naming convention subject.commonName

The following requirements apply to the CommonName of the Subject field. The main principle is that the TSP is responsible for correct entry of the CommonName. For a correct implementation this entails that the TSP has to be able to check each part that is entered. The CommonName has the following format [3]:

[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]

whereby:

• text in bold = compulsory part
• Italic = compulsory part, style in accordance with Compulsory Identification Act document or presented Local Council Personal Records Database extract
• normal = optional part; if present, the style has to be the same as the Compulsory Identification Act document or the presented Local Council Personal Records Database extract

In principle, the TSP decides whether or not optional parts are allowed. If it prefers, the TSP can leave the choice for an option to the subscriber or the party requesting the certificate. If the CommonName becomes too long for the number of characters that are allowed, optional parts have to be omitted (starting with the replacement of other forenames by initials from the last to the first position) until the name fits in the maximum field length.

[3]: The presented order is not compulsory, the surname can also be given first followed by forenames/initials.

10.3 Personal certificates

10.3.1 Basic attributes

10.3.2 Standard extensions

10.3.3 Private extensions

11 Revisions

11.1 Amendments from version 4.6 to 4.7

11.1.1 New

• Requirement 3.2.5-pkio160, list of limitative professions (transferred from PvE part 4) (effective date immediately after publication PVE 4.7)
• Requirement 7.1-pkio177 (effective date immediately after publication PVE 4.7)
• Requirement 3.2.3-pkio169 (effective date 4 weeks after publication of PVE 4.7)

11.1.2 Modifications

• Authentic proof for practicing a recognized profession combined in requirement 3.2.5-pkio29 (effective date immediately after publication PVE 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.
• Limitative list of professions updated, “municipal” tax bailiff (latest effective date 4 weeks after publication of PVE 23)
• Description of a number of certificate attributes replaced by reference to requirement 7.1-pkio174 (effective date 8 weeks after publication PVE 4.7)

11.2 Amendments from version 4.5 to 4.6

11.2.1 Modifications

• Modified reference to ETSI certificate profiles (effective date directly after publication of PoR 4.6)
• Certificate profile, remove exception subject.surname and subject.givenname (effective date directly after publication of PoR 4.6)

11.3 Amendments from version 4.4 to 4.5

11.3.1 New

• Mandatory English CPS (requirement 2.2-pkio3, effective date 1-10-2017)
• Mandatory yearly renewal CPS (requirement 2.2-pkio156, effective date 1-1-2017)

11.3.2 Modifications

• Requirement 4.9.9-pkio67 now references RFC6960 instead of RFC2560 (effective date 31-12-2016)
• Allow/require EKU emailProtection in authenticity and non-repudiation certificates in requirement 7.1-pkio149 (effectrive date1-4-2017)
• Change in OID 2.16.528.1.1003.1.2.5.1 to also cover OCSP responder certificates (effective date 1-7-2017)
• Mandatory use of field “NextUpdate” in OCSP responses (requirement 4.9.9-pkio71, effective date 1-7-2017)

11.3.3 Editorial

• Removed typos from certificate profile.

11.4 Amendments from version 4.3 to 4.4

11.4.1 Modifications

• Removal of requirement 5.3.2-pkio79 (effective date 1-2-2017)
• Clarification of issuer.organizationIdentifier field (effective date 1-2-2017)
• Tightening of use optional EKUs that conflict with the parent TSP CA certificate (effective date 1-2-2017)

11.4.2 Editorial

• Replaced CSP (Certificate Service Provider) with TSP (Trust Service Provider) in accordance with eIDAS directive.

11.5 Amendments from version 4.2 to 4.3

11.5.1 New

• Addition of issuer.organizationalIdentifier in the certificate profile (effective date 1-7-2016)

11.5.2 Modifications

• Description with attribute CertificatePolicies (effective date 1-7-2016)
• Removal optional use KeyAgreement with Key Usage (effective date no later than 4 weeks after publication of PoR 4.3)
• Mandatory QcStatement qualified certificate (effective date 1-7-2016)
• ETSI TS 102 176-1 replaced by ETSI TS 119 312 (effective date no later than 4 weeks after publication of PoR 4.3)
• Use of values in BasicConstraints field no longer permitted in end entity certificates (effective date 1-7-2016)
• Use of”Any ExtendedKeyUsage” in end entity certificates no longer permitted (effective date 1-11-2016)

11.5.3 Editorial

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

11.6 Amendments from version 4.1 to 4.2

11.6.1 New

• Requirement 7.1-pkio149 (effective date 1 july 2016)

11.6.2 Modifications

None

11.6.3 Editorial

None

11.7 Amendments from version 4.0 to 4.1

11.7.1 New

• Certification against ETSI TS 102 042 (effective date no later than 4 weeks after publication of PoR 4.1)

11.7.2 Modifications

• Description of the attribute Subject.organizationName (effective date no later than 4 weeks after publication of PoR 4.1)

11.7.3 Editorial

• Small editiorial changes to the following requirements:
  • 3.1.3-pkio11;
  • 3.2.5-pkio32;
  • 5.7.4-pkio86;
  • 9.6.1-pkio131.

11.8 Amendments from version 3.7 to 4.0

11.8.1 New

• Requirement 5.5.1-pkio82

11.8.2 Modifications

• PoR requirements have been renumbered according to a new naming convention;
• The creation of a document containing the baseline and additional requirements;
• Changes to requirements can be found in the baseline and additional requirements documents respectively.

11.8.3 Editorial

Editorial changes to requirements can be found in the baseline and additional requirements documents respectively. These changes have no effect on the content of the information.