Programme of Requirements part 3c: Certificate Policy - Citizen Domain v4.7
Table of Contents
1 Introduction to the Certificate Policy
1.1.1 Design of the Certificate Policy
1.5 Contact information Policy Authority
2 Publication and Repository Responsibilities
2.2 Publication of TSP information
3 Identification and Authentication
3.2 Initial Identity Validation
3.3 Identification and Authentication for Re-key Requests
4 Certificate Life-Cycle Operational Requirements
4.5 Key Pair and Certificate Usage
4.9 Certificate Revocation and Suspension
4.10 Certificate Status Service
5 Facility, Management and Operational Controls
5.7 Compromise and Disaster Recovery
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.5 Computer Security Controls
6.6 Life Cycle Technical Controls
7 Certificate, CRL and OSCP profiles
8 Compliance Audit and Other Assessments
9 Other Business and Legal Matters
9.5 Intellectual Property Rights
9.6 Representations and Warranties
9.13 Dispute Resolution Procedures
Appendix A Certificate profiles
10.1 Amendments from version 4.6 to 4.7
10.2 Amendments from version 4.5 to 4.6
10.3 Amendments from version 4.4 to 4.5
10.4 Amendments from version 4.3 to 4.4
10.5 Amendments from version 4.2 to 4.3
10.6 Amendments from version 4.1 to 4.2
10.7 Amendments from version 4.0 to 4.1
10.8 Amendments from version 3.7 to 4.0
The Policy Authority ( PA ) of the PKI for the government supports the Minister of the Interior and Kingdom Relations in managing the PKI for the government.
The PKI for the government is an agreements system. 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 PKI for the government, the Programme of Requirements ( PoR );
· assisting in the process of admittance by TrustService Providers ( TSP s) to the PKI for the government and preparing the administration;
· supervising and monitoring the activities of TSP s that issue certificates under the root of the PKI for the government.
The purpose of the Policy Authority is:
Enforcement of a practicable and reliable framework of standards for PKI services that provides an established level of security for the government's communication needs that is transparent to users.
Revision control
Version |
Date |
Description |
4.0 |
12-2014 |
Ratified by the Ministry of the Interior and Kingdom Relations December 2014 |
4.1 |
07-2015 |
Ratified by the Ministry of the Interior and Kingdom Relations July 2015 |
4.2 |
01-2016 |
Ratified by the Ministry of the Interior and Kingdom Relations January 2016 |
4.3 |
07-2016 |
Ratified by the Ministry of the Interior and Kingdom Relations July 2016 |
4.4 |
02-2017 |
Ratified by the Ministry of the Interior and Kingdom Relations February 2017 |
4.5 |
07-2017 |
Ratified by the Ministry of the Interior and Kingdom Relations July 2017 |
4.6 |
01-2018 |
Ratified by the Ministry of the Interior and Kingdom Relations January 2018 |
4.7 |
01-2019 |
Ratified by the Ministry of the Interior and Kingdom Relations February 2019 |
1 Introduction to the Certificate Policy
1.1 Overview
This is part 3c of the Programme of Requirements ( PoR ) for the PKI for the government and is known as 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 Trust 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 a TSP in the Citizen domain.
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 current version of the ETSI EN 319-411-2, QCP -n-qscd ( ETSI CP OID 0.4.0.194112.1.2) for non-repudiation certificates;
· that ensue from the current version of the ETSI EN 319 411-1 standard where policy NCP + + is applicable to authenticity and confidentiality 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).
RFC 3647 |
Reference to the paragraph from the RFC 3647 structure to which the PKIo requirement relates. RFC 3647 is a PKIX framework of the Internet Engineering Task Force ( IETF ) and is the de facto standard for the structure of Certificate Policies and Certification Practice Statements [2] . |
Number |
Unique number of the PKIo requirement. In each paragraph, consecutive numbering is used for the PKIo requirements. In combination with the RFC 3647 paragraph number, this forms a unique label for the 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 TSP s 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.1.2 Status
This is version 4.7 of part 3c of the PoR . The current version has been updated up to 8 February 2019 inclusive.
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 -2 56 algorithm ( G2 and G3 ). Furthermore these structures are divided into different domains.
The G2 root is divided into an Organization, a Citizen and an 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.
OID |
CP |
2.16.528.1.1003.1.2.3.1 |
for the authenticity certificate, that contains the public key for identification and authentication. Under this OID OCSP certificates may be issued for use within the context of this CP part. |
2.16.528.1.1003.1.2.3.2 |
for the signature certificate, that contains the public key for the qualified electronic signature |
2.16.528.1.1003.1.2.3.3 |
for the confidentiality certificate that contains the public key for confidentiality |
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). citizen domain (3). 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 CP s.
1.3 User Community
In the Government and Companies domain, the Organization domain and the Organization Person domain the distinction between subscriber and certificate holder is relevant because, in practice, the following situation is anticipated: the TSP has an agreement with the subscriber which stipulates that the TSP will issue certificates to the certificate holders to be appointed by the subscriber (for example, the subscriber's employees). In the Citizen domain, the subscriber and certificate holder are the same person. Where the subscriber is listed in the CP Citizen, this has to interpreted as certificate holder. The citizen takes on the obligations of both the subscriber and the certificate holder.
Within the Citizen domain, the user community consists of certificate holders (the citizens that use the certificates) and relying parties who act with trust in certificates of the relevant certificate holders.
The parties within the user community are subscribers, certificate holders and relying parties.
· A subscriber is a natural person who enters into an agreement with a TSP for certification of the public keys. A subscriber is also 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.
· 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 in a private capacity.
[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. More information can be obtained in appendix A of the base requirements.
[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).
[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.
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
RFC 3647 |
2.2 Publication of TSP information |
Number |
2.2-pkio3 |
RFC 3647 |
2.2 Publication of TSP information |
Number |
2.2-pkio7 |
RFC 3647 |
2.2 Publication of TSP information |
Number |
2.2-pkio156 |
3 Identification and Authentication
3.1 Naming
RFC 3647 |
3.1.3 Anonymity or pseudonimity of certificate holders |
Number |
3.1.3-pkio11 |
3.2 Initial Identity Validation
RFC 3647 |
3.2.3 Authentication of individual identity |
Number |
3.2.3-pkio21 |
RFC 3647 |
3.2.3 Authentication of individual identity |
Number |
3.2.3-pkio169 |
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.4 Certificate Acceptance
Contains no additional requirements.
4.5 Key Pair and Certificate Usage
Contains no additional requirements.
4.9 Certificate Revocation and Suspension
RFC 3647 |
4.9.1 Circumstances for revocation |
Number |
4.9.1-pkio52 |
RFC 3647 |
4.9.3 Procedure for revocation request |
Number |
4.9.3-pkio57 |
RFC 3647 |
4.9.7 CRL issuance frequency |
Number |
4.9.7-pkio65 |
RFC 3647 |
4.9.9 On-line revocation/status checking availability |
Number |
4.9.9-pkio66 |
RFC 3647 |
4.9.9 On-line revocation/status checking availability |
Number |
4.9.9-pkio67 |
RFC 3647 |
4.9.9 On-line revocation/status checking availability |
Number |
4.9.9-pkio68 |
RFC 3647 |
4.9.9 On-line revocation/status checking availability |
Number |
4.9.9-pkio70 |
RFC 3647 |
4.9.9 On-line revocation/status checking availability |
Number |
4.9.9-pkio71 |
4.10 Certificate Status Service
Contains no additional requirements.
5 Facility, Management and Operational Controls
5.2 Procedural Controls
Contains no additional requirements.
5.3 Personnel Controls
Contains no additional requirements.
5.4 Audit Logging Procedures
RFC 3647 |
5.4.1 Types of events recorded |
Number |
5.4.1-pkio80 |
5.5 Records Archival
Contains no additional requirements.
5.7 Compromise and Disaster Recovery
RFC 3647 |
5.7.4 Business continuity capabilities after a disaster. |
Number |
5.7.4-pkio861 |
6 Technical Security Controls
6.1 Key Pair Generation and Installation
RFC 3647 |
6.1.1 Key pair generation for the TSP sub CA |
Number |
6.1.1-pkio87 |
RFC 3647 |
6.1.1 Key pair generation for the certificate holders |
Number |
6.1.1-pkio88 |
RFC 3647 |
6.1.1 Key pair generation for the certificate holders |
Number |
6.1.1-pkio89 |
RFC 3647 |
6.1.2 Private key and SSCD delivery to certificate holder |
Number |
6.1.2-pkio94 |
6.2 Private Key Protection and Cryptographic Module EngineeringControls
RFC 3647 |
6.2.3 Private key escrow of certificate holder key |
Number |
6.2.3-pkio99 |
RFC 3647 |
6.2.3 Private key escrow of certificate holder key |
Number |
6.2.3-pkio100 |
RFC 3647 |
6.2.3 Private key escrow of certificate holder key |
Number |
6.2.3-pkio101 |
RFC 3647 |
6.2.11 Cryptographic module rating |
Number |
6.2.11-pkio104 |
RFC 3647 |
6.2.11 Cryptographic module rating |
Number |
6.2.11-pkio105 |
RFC 3647 |
6.2.11 Cryptographic module rating |
Number |
6.2.11-pkio106 |
6.3 Other Aspects of Key Pair Management
RFC 3647 |
6.3.1 Public key archival |
Number |
6.3.1-pkio108 |
RFC 3647 |
6.3.2 Certificate operational periods and key pair usage periods |
Number |
6.3.2-pkio109 |
6.4 Activation data
RFC 3647 |
6.4.1 Activation data generation and installation |
Number |
6.4.1-pkio112 |
RFC 3647 |
6.4.1 Activation data generation and installation |
Number |
6.4.1-pkio113 |
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
RFC 3647 |
7.1 Certificate Profile |
Number |
7.1-pkio149 |
RFC 3647 |
7.1 Certificate Profile |
Number |
7.1-pkio177 |
7.2 CRL Profile
Contains no additional requirements.
7.3 OCSP Profile
RFC 3647 |
7.3 OCSP profile |
Number |
7.3-pkio123 |
8 Compliance Audit and Other Assessments
All subjects relating to the conformity assessment of the TSP s within the PKI for the government are covered in PoR part 2 And the basic requirements.
9 Other Business and Legal Matters
9.2 Financial Responsibility
RFC 3647 |
9.2.1 Insurance coverage |
Number |
9.2.1-pkio124 |
9.5 Intellectual Property Rights
Contains no additional requirements.
9.6 Representations and Warranties
RFC 3647 |
9.6.1 CA Representations and Warranties by TSP s |
Number |
9.6.1-pkio127 |
RFC 3647 |
9.6.1 CA Representations and Warranties by TSP s |
Number |
9.6.1-pkio129 |
RFC 3647 |
9.6.1 CA Representations and Warranties by TSP s |
Number |
9.6.1-pkio131 |
RFC 3647 |
9.6.1 CA Representations and Warranties by TSP s |
Number |
9.6.1-pkio132 |
9.8 Limitations of Liability
RFC 3647 |
9.8 Limitations of liability |
Number |
9.8-pkio133 |
9.12 Amendments
Contains no additional requirements.
9.13 Dispute Resolution Procedures
Contains no additional requirements.
9.14 Governing Law
Contains no additional requirements.
9.17 Other provisions
RFC 3647 |
9.17 Miscellaneous provisions |
Number |
9.17-pkio139 |
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.
Appendix A Certificate profiles
Profile of the certificate for the Citizen domain
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.
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'.
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, style in accordance with Compulsory Identification Act document or presented Local Council Personal Records Database extract
Italic = compulsory part, choice from two options (full forenames or initials)
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.
Citizen certificates
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 |
OID |
MUST be the same as the field signatureAlgorithm. For certificates under the G2 and 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 |
Printable String |
|
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 |
Printable String |
|
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 |
The organizationalIdentifier field contains an identification of the issuing CA . This field MUST be present when the field subject.organizationIdentifier is present in the TSP certificate and MUST NOT be present when this field is not present in the TSP certificate. |
EN 319 412-1 |
String |
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 CRL Profile"> RFC 5280. |
CRL Profile"> 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 subscriber's address in accordance with the accepted document or registry. |
Subject.commonName |
V |
The commonName attribute MUST be entered in accordance with the Naming Convention Subject.commonName paragraph shown above. |
RFC 3739 , ETSI TS 102 280, PKIo |
UTF8String |
The contents of this field MUST correspond with the name given in the GBA . The Compulsory Identification Act document or other evidence (excerpt from the population register) can be used to demonstrate this. The use of commas as punctuation in the commonName is advised against due to possible technical conflicts when processing the certificate. |
Subject.Surname |
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.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 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 holder's branch in accordance with an accepted document or Basic registry. |
PKIo, RFC 3739 |
UTF8String |
Name of the province MUST correspond with the certificate holder's 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 holder's address in accordance with the GBA . The certificate holder will have to submit recent proof of his address. |
Subject.postalAddress |
A |
The use is advised against. If present, this field MUST contain the certificate holder's postal address in accordance with an accepted document or Basic registry. |
PKIo, RFC 3739 |
UTF8String |
The address MUST correspond with the certificate holder's 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 and Serialnumber MUST be unique within the context of the TSP . |
RFC 3739 , X 520, PKIo |
Printable String |
The serial number is intended to enable a distinction to be made between subjects with the same commonName. To avoid susceptibilities a serial Number 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, CRL Profile"> RFC 5280 |
BitString |
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 . |
CRL Profile"> RFC 5280 |
BitString |
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 being essential. Another keyUsage MUST NOT be combined with this. In confidentiality certificates, keyEncipherment and dataEncipherment bits MUST be incorporated and marked as being essential. Another keyUsage MUST NOT be combined with this. In certificates for the electronic signature the non-repudiation bit MUST be incorporated and marked as being essential. Another keyUsage MUST NOT be combined with this. |
RFC 3739 , CRL Profile"> RFC 5280, ETSI TS 102 280 |
BitString |
|
CertificatePolicies |
V |
No |
MUST contain the OID of the certificate policy ( CP ), the URI of the certification practice statement ( CPS ), and a user notice. The applicable PKI for the government OID scheme is described in the CP . The TSP SHOULD use UTF8String in the userNotice, but MAY use IA5String. |
RFC 3739 |
OID , String, UTF8String or IA5String |
For the Citizen domain, the OID s are: 2.16.528.1.1003.1.2.3.1, 2.16.528.1.1003.1.2.3.2 and 2.16.528.1.1003.1.2.3.3. Reference to the paragraph numbers of the PoR / CP 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 |
MUST be used and given a personal worldwide unique identification number. |
RFC 4043, CRL Profile"> RFC 5280, PKIo, ETSI 102 280 |
MUST include a unique identifier in the othername attribute. Attributes other than those mentioned below MUST NOT be used. |
|
SubjectAltName.otherName |
V |
MUST be used containing a unique identification number that identifies the certificate holder. An additional othername entry MAY be included in the authentication certificate for use with SSO (Single Sign On). |
PKIo |
IA5String, Microsoft UPN, IBM Principal-Name, Kerberos PrincipalName or Permanent-Identifier |
Includes an OID of the TSP awarded by the PA to the TSP and a number that is unique within the namespace of that OID that permanently identifies the subject, in one of the following ways: 1. MS UPN: [number]@[OID] 2. MS UPN: [OID].[number] 3. IA5String: [OID]-[number] 4. Permanent Identifier: Identifiervalue = [number] Assigner = [OID] Alternative 1. is also suitable for SSO . If a second othername for SSO is given in the certificate, the SSO othername MUST be given first in the SubjectAltName, before the PKIoverheid format othername described above, in order to ensure the proper operation of the SSO mechanism. It is recommended that an existing registration number from back office systems is used, in combination with a code for the organization. In combination with the TSP OID , this identifier is internationally unique. This number MUST be persistent. |
|
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. |
CRL Profile"> 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 |
The " CA " field MUST be omitted (default value is then "FALSE"). |
CRL Profile"> RFC 5280 |
A (Dutch language) browser can then be seen: "Subjecttype = Eindentiteit", "Beperking voor padlengte = Geen" ("Subject type = End Entity", "Path length constraint = None") |
|
CRLDistributionPoints |
V |
No |
MUST include the URI of a CRL distribution point. |
CRL Profile"> 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 |
CRL Profile"> RFC 5280 |
See requirement 7.1-pkio149 |
||
FreshestCRL |
O |
No |
MUST contain the URI of a Delta CRL distribution point, if Delta CRL s are used. |
CRL Profile"> RFC 5280, PKIo |
Delta-CRLs are an optional extension. In order to fulfil the requirements of PKIoverheid a TSP MUST also publish full CRL s at the required release frequency. |
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 . |
||
SubjectInfoAccess |
O |
No |
CRL Profile"> RFC 5280 |
OID , Generalname |
This field can be used to reference additional information about the subject, provided that the information that is offered does not infringe the privacy of the subject. |
|
BiometricInfo |
O |
No |
Contains the hash of a biometric template and optionally a URI that references a file with the biometric template itself. |
RFC 3739 |
||
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-esignstatement 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-QcPDSstatement 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 |
OID |
The aforementioned QcStatement identifiers relate to the following OID s: · 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 |
10 Revisions
10.1 Amendments from version 4.6 to 4.7
10.1.1 New
· Requirement 7.1-pkio177 (effective date immediately after publication PoR 4.7)
· Requirement 3.2.3-pkio169 (effective date 4 weeks after publication of PoR 4.7)
10.1.2Modifications
· Description of a number of certificate attributes replaced by reference to requirement 7.1-pkio174 (effective date 8 weeks after publication PoR 4.7)
· Reference to CWA 14 169 amended to EN 419 211 for QSCD s. This also sets requirements for the issue of QSCD s 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 (effective date immediately after publication PoR 4.7)
10.2Amendments from version 4.5 to 4.6
10.2.1Modifications
· Modified reference to ETSI certificate profiles (effective date directly after publication of PoR 4.6)
· Certificate profile, removed exeption subject.surName and subject.givenName (effective date directly after publication of PoR 4.6)
· Corrected subjectAltName.othername field (effective date directly after publication of PoR 4.6)
10.3 Amendments from version 4.4 to 4.5
10.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)
10.3.2Modifications
· Requirement 4.9.9-pkio67 now references RFC 6960 instead of RFC 2560 (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.3.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)
10.3.3 Editorial
· Removed typos from certificate profile.
10.4 Amendments from version 4.3 to 4.4
10.4.1 New
None
10.4.2 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 EKU s that conflict with the parent TSP CA certificate (effective date 1-2-2017)
· Probihition use of QCStatement with authenticity and confidentiality certificate (equalization of parts a, c &I, effective date 1-2-2017)
10.4.3 Editorial
· Replaced CSP (Certificate Service Provider) with TSP (Trust Service Provider) in accordance with eIDAS directive.
10.5 Amendments from version 4.2to 4.3
10.5.1 New
· Addition of Issuer.organizationalIdentifier in the certificate profile ( effective date 1-7-2016)
10.5.2 Modifications
· Description with attribute CertificatePolicies ( effective date 1-7-2016)
· Removal of optional use KeyAgreement with Key Usage (effective date no later than 4 weeks after publication of PoR 4.3)
· Mandatory QcStatement in 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 the BasicConstraints field no longer permitted in end entity certificates (effective date 1-7-2016)
· ETSI TS 102 042 replaced by ETSI EN 319 411-1 ( effective date 1-7-2016 or when the accreditation to the certifying body has been granted with a final date of 30 June 2017)
10.5.3 Editorial
· Removed references to G1 Root (expired)
10.6 Amendments from version 4.1to 4.2
10.6.1 New
· Requirement 7.1-pkio149 (effective date 1 juli 2016)
10.6.2 Modifications
None
10.6.3 Editorial
None
10.7 Amendments from version 4.0 to 4.1
10.7.1 New
· Certification against ETSI TS 102 042(effective date no later than 4 weeks after publication of PoR 4.1 );
10.7.2 Modifications
· None
10.7.3 Editorial
· Small editorial modifications to the following requirements:
o3.1.3-pkio11;
o5.7.4-pkio86;
o9.6.1-pkio131.
10.8 Amendments from version 3.7 to 4.0
10.8.1 New
· None
10.8.2Modifications
· 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.
10.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.
[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.
[3] The presented order is not compulsory, the surname can also be given first followed by forenames/initials.
