Table of Contents

OID

CP

2.16.528.1.1003.1.2.5.1

for the authenticity certificate within the Organization and Organization Person domain, 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.5.2

for the signature certificate within the Organization and Organization Person domain, that contains the public key for the qualified electronic signature/non repudiation

2.16.528.1.1003.1.2.5.3

for the confidentiality certificate within the Organization and Organization Person domain, 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). 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 CP s.

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 andRepository 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-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.2 Authentication of organizational entity
Number	3.2.2-pkio14

RFC 3647	3.2.2 Authentication of organizational entity
Number	3.2.2-pkio16

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

RFC 3647	3.2.5 Validation of authority
Number	3.2.5-pkio29

RFC 3647	3.2.5 Validation of authority
Number	3.2.5-pkio32

RFC 3647	3.2.5 Validation of authority
Number	3.2.5-pkio160

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 Services

Contains no additional requirements.

5 Facility, Management and OperationalControls

5.2 ProceduralControls

Contains no additional requirements.

5.3 PersonnelControls

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

RFC 3647	5.5.1 Types of records archived
Number	5.5.1-pkio82

5.7 Compromise and Disaster Recovery

RFC 3647	5.7.4 Business continuity capabilities after a disaster.
Number	5.7.4-pkio86

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 Engineering Controls

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

RFC 3647	6.2.11 Cryptographic module rating
Number	6.2.1-pkio105

RFC 3647	6.2.11 Cryptographic module rating
Number	6.2.1-pkio106

6.3 Other Aspects of Key Pair Management

RFC 3647	6.3.1 Public key archival
Number	6.3.2-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 Provisions

Contains no additional requirements.

9.14 Governing Law

Contains no additional requirements.

9.17 Other provisions

RFC 3647	9.17 Other 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 Profiles certificates

Profile of the certificate for the Organization and Organization Person domains

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

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.

Personal certificates

Basic attributes

Field / Attribute	Criteria	Description	Standard reference	Type	Explanation
Version	V	MUST be set at 2 ( X.509v3 ).	CRL Profile"> 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.	CRL Profile"> RFC 5280	Integer	All end user certificates have to contain at least 8 bytes of unpredictable random data in the certificate's serial number (SerialNumber).
Signature	V	MUST be set on the algorithm, as stipulated by the PA .	CRL Profile"> 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 requirement 7.1-pkio174	ETSI TS 101862, X520 , ISO 3166	Printable String
Issuer.OrganizationName	V	See requirement 7.1-pkio174	ETSI TS 102280	UTF8String
Issuer. organizationalUnitName	O	See requirement 7.1-pkio174	ETSI TS 102280: 5.2.4	UTF8String
Issuer.serialNumber	O	See requirement 7.1-pkio174	RFC 3739	Printable String
Issuer.commonName	V	See requirement 7.1-pkio174	PKIo, RFC 3739	UTF8String	The commonName attribute MUST NOT be necessary in order to identify the issuing government body (no part of the Distinguished Name, requirement from RFC 3739 )
Issuer.organizationIdentifier	V/N	The organizationIdentifier field contains an identification of the issuing CA . This field MUST be present when the organizationIdentifier is present in the TSP certificate and MUST NOT be present when the organizationIdentifier is 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 and include information about the subscriber. The field has the following attributes	PKIo, RFC 3739, ETSI TS 102 280		MUST contain a Distinguished Name ( DN ). Attributes other than those mentioned below MUST NOT be used.
Subject.countryName	V	complete C with two-letter country code in accordance with ISO 3166 -1. If an official alpha-2 code is missing, the TSP MAY use the user-assigned code XX.	RFC 3739 , X520 , ISO 3166 , PKIo	Printable String	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 paragraph Naming convention Subject.commonName above.	RFC 3739 , ETSI TS 102 280, PKIo	UTF8String	See the naming convention of Subject.commonName.
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 surname including surname prefixes correctly, as shown on the Compulsory Identification Act document.
Subject.organizationName	V	Full name of the subscriber in accordance with the accepted document or Basic Registry	PKIo	UTF8String	The subscriber is the entity with which the TSP has entered into an agreement and on behalf of which or pursuant to which the certificate holder acts when using the certificate. In occupational-linked certificates this is equal to the common name of the certificate holder.
Subject.organizationalUnitName	O	Optional specification of an organizational entity. This attribute MUST NOT include a function indication or similar.	PKIo		This attribute MAY appear several times in organization-linked certificate holders. The field MUST contain a valid name of an organizational entity of the subscriber in accordance with an accepted document or registry In occupational-linked certificate holders, this attribute MUST NOT be incorporated.
Subject.stateOrProvinceName	A	The use is advised against. If present, this field MUST contain the province in which the subscriber is established in accordance with an accepted document or Basic registry.	PKIo, RFC 3739	UTF8String	Name of the province MUST correspond with the address of the subscriber in accordance with the accepted document or registry.
Subject.localityName	A	The use is advised against. If present, this field MUST contain the location of the subscriber in accordance with an accepted document or Basic registry.	PKIo, RFC 3739	UTF8String	Name of the location MUST correspond with the address of the subscriber in accordance with the accepted document or registry.
Subject.postalAddress	A	The use is advised against. If present, this field MUST contain the postal address of the subscriber in accordance with an accepted document or Basic registry.	PKIo, RFC 3739	UTF8String	The address MUST correspond with the address of the subscriber in accordance with the accepted document or registry.
Subject.serialNumber	V	Number to be determined by the TSP . The combination of CommonName, OrganizationName and Serialnumber MUST be unique within the context of the TSP .	RFC 3739 , X 520, PKIo	Printable String	The serialnumber is intended to distinguish between subjects with the same commonName and the same OrganizationName. To avoid susceptibilities a serial Number attribute MUST be allocated to every subject.
Subject.title	O	Includes the position/function/profession/professional group of a subject.	ETSI TS 102 280, RFC 3739 , CRL Profile"> RFC 5280		This attribute preferably gives static, verifiable professional titles (doctor, pharmacist, etc.), NOT the term of address (Mr, Mrs, etc.).
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 critical. Another keyUsage MUST NOT be combined with this. In confidentiality certificates, keyEncipherment and dataEncipherment bits MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this. In certificates for the electronic signature the non-repudiation bit MUST be incorporated and marked as critical. Another keyUsage MUST NOT be combined with this.	RFC 3739 , 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 Government/Companies domain, the OID s are: 2.16.528.1.1003.1.2.2.1, 2.16.528.1.1003.1.2.2.2 and 2.16.528.1.1003.1.2.2.3. For the Organization and Organization Person domains, the OID s are: 2.16.528.1.1003.1.2.5.1, 2.16.528.1.1003.1.2.5.2 and 2.16.528.1.1003.1.2.5.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 ). If this concerns a profession-linked certificate, it is preferable to make a note of the fact in the user notice that the certificate holder is acting in the capacity of his/her profession.
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. In addition, in the authentication certificate, an 'othername' MAY be included for use with Single Sign On ( SSO ).	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 numberthat 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 in the Government/Companies and Organization domains, the use of e-mail addresses is advised again, because e-mail addresses of certificate holders often change and furthermore are privacy sensitive (spam). If the e-mail address is included in the certificate, the TSP MUST: · have the subscriber sign his/her approval for these and; · check that the e-mail address belongs to the subscriber's domain, or; · check that the e-mail address belongs to the subscriber ( e.g. the professional) and that this person has access to the e-mail address (for example by performing a challenge response).
subjectDirectoryAttributes	O	No		CRL Profile"> RFC 5280; RFC 3739		The use of this extension is allowed. These attributes MAY NOT contain personal data that can impair the subject's privacy.
BasicConstraints	O	Yes	The " CA " field MUST be 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	KeyPurposeId's	· 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 extension.	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 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)

10.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 QSCD s. This also sets requirements for issuing 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.

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

10.2 Amendments from version 4.5 to 4.6

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

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

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

10.3.3 Editorial

· Removed typos from certificate profile.

10.4 Amendments from version 4.3 to 4.4

10.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 EKU s that conflict with the parent TSP CA certificate (effective date 1-2-2017)

10.4.2 Editorial

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

10.5 Amendments from version 4.2 to 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 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)

10.5.3 Editorial

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

10.6 Amendments from version 4.1 to 4.2

10.6.1 New

· Requirement 7.1-pkio149 (effective date 1 july 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

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

10.7.3 Editorial

· Small editiorial changes to the following requirements:

o3.1.3-pkio11;

o3.2.5-pkio32;

o5.7.4-pkio86;

o9.6.1-pkio131.

10.8 Amendments from version 3.7 to 4.0

10.8.1 N ew

· Requirement 5.5.1-pkio82

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

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.