Programme of Requirements part 3b: Certificate Policy for authenticity, confidentiality and non-repudiation certificates in Organization Services (G3) Domain v4.10

Table of Contents

1. INTRODUCTION

Refer to Programme of Requirements part 3 Basic Requirements.

1.2 Document name and identification

1.2.1 Revisions

1.2.1.1 Version 3.7 to 4.0

New

None.

Modifications

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

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.2.1.2 Version 4.0 to 4.1

New

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

Modifications

• Requirement 6.3.2-pkio109 (effective date no later than 4 weeks after publication of PoR 4.1).

Editorial

• Small editiorial change to the following requirements:

  • Requirement 5.7.4-pkio86.

1.2.1.3 Version 4.1 to 4.2

New

• Requirement 6.3.2-pkio148 (effective date no later than 4 weeks after publication of PoR);
• Requirement 7.1-pkio150 (effective date 1 July 2016).

Modifications

• Certificate profile: changed use of subjectAltName from “prohibited toegestaan” to “optional”;
• Ban on issuance of 5 year services certificates to 3 year: removed requirements 6.3.2.-pkio109 and added 6.3.2-pkio148.

Editorial

None.

1.2.1.4 Version 4.2 to 4.3

New

• Pkio153: additional requirements on the use of qualified seals (effective date 1-7-2016);
• New policyidentifier and profile modifications for the use of qualified seals (effective date 1-7-2016);
• Addition of Issuer.organizationalIdentifier in the certificate profile (effective date 1-7-2016).

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);
• ETSI TS 102 176-1 replaced by ETSI TS 119 312 (effective date no later than 4 weeks after publication of PoR 4.3);
• Dropped requirement pkio95 because of i.v.m. duplicate requirement in ETSI EN 319 411-1;
• 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);
• Requirement 7.1-pkio150 modified (removed not permitted EKU) (effective date 1-11-2016).

Editorial

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

1.2.1.5 Version 4.3 to 4.4

New

None.

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

Editorial

• Moved QCStatements from Public to Private Extensions;
• Replaced CSP (Certificate Service Provider) with TSP (Trust Service Provider) in accordance with eIDAS directive.

1.2.1.6 Version 4.4 to 4.5

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

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 (effective date1-4-2017);
• Change in OID 2.16.528.1.1003.1.2.5.4 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).

Editorial

• Removed typos from certificate profile.

1.2.1.7 Version 4.5 to 4.6

New

None.

Modifications

• Added subject.organizationIdentifier in the certificate profile to fix an ommission (effective date directly after publication of PoR 4.6);
• Modified reference to ETSI certificate profiles (effective date directly after publication of PoR 4.6);
• Corrected subjectAltName.othername field (effective date directly after publication of PoR 4.6).

Editorial

None.

1.2.1.8 Version 4.6 to 4.7

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

Modifications

• 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 QSCDs. This also sets requirements for the issue of QSCDs for requirements 6.1.1-pkio88, 6.1.1-pkio93, 6.1.1-pkio153, 6.2.11-pkio105, 6.4.1-pkio112 and 4.9.1-pkio52 (effective date immediately after publication PoR 4.7);
• Requirement 6.3.2-pkio148 expired and is replaced by requirement 6.3.2-pkio109 (effective date immediately after publication of PoR 4.7).

Editorial

None.

1.2.1.9 Version 4.7 to 4.8

New

• New requirement 3.2.2-pkio186 on (re)validation of organizational data (effective date immediately after publication PoR 4.8).

Modifications

• Change in requirement 7.1-pkio150 to enable usage of constraint (EKU emailProtection) in PoR (effective date immediately after publication PoR 4.8);
• Requirement 9.17-pkio140 removed (effective date immediately after publication PoR 4.8);
• Changes in serial number requirements in requirement 7.1-pkio173 (effective date August 29, 2019).

Editorial

• Changes in definition of private key in requirement 4.9.1-pkio52 (effective date immediately after publication PoR 4.8).

1.2.1.10 Version 4.8 to 4.9

New

• Introducing new additional requirement 2.2-PKIo191 for RFC 3647 compliance in PoR Part 3b (effective date after 01-04-2020).

• Created new requirement 8.1-pkio189 as an Additional Requirement for PoR Part 3b (effective date 02-17-2020).

• Created new requirement 4.9.1-pkio192 on certificate revocation as an Additional Requirement for PoR Part 3b (effective date 02-17-2020).

Modifications

• Change requirements 6.1.1-pkio89 to comply with Mozilla policy on signature encoding (effective date 01-03-2020).

• Removed PoR Part 3b from scope of additional requirement 4.9.1-pkio52 (effective date immediately after publication PoR 4.9).

Removals:

• Requirement 6.1.1-pkio87 has been deleted (effective date immediately after publication PoR 4.9).

• Requirement 2.2-pkio8 has been deleted (effective date immediately after publication PoR 4.9).

Editorial

None.

1.2.1.11 Version 4.9 to 4.10

New

• Added basic requirement 8.2-pkio199.

• Added new additional requirement 8.4-pkio195.

• Added new additional requirement 8.4-pkio200.

Modifications

• Change the description and criteria of the subject:organizationalUnitName attribute in the certificate profile.

• Changes to the subject:organizationIdentifier attribte in the certificate profile.

• Change the description, explanation, and criterium of the extensions:subjectAltName:otherName attribute in the certificate profile.

• Expand the description of the extensions:certificatePolicies field in the certificate profile with additional ETSI 319 411 certificate policies.

• Change the extensions:certificatePolicies:policyQualifiers:qualifier:userNotice field criteria to "MAY" in the certificate profile.

• Replace Telecommunications Act with eDIAS in requirement 9.6.1-pkio127.

Removals

• Remove the subject:postalAddress attribute from the certificate profile.

• Remove the extensions:freshestCRL field from the certificate profile.

• Remove the extensions:subjectInfoAccess field from the certificate profile.

• Remove requirement 9.6.1-pkio129.

Editorial

• Editorial changes in the description and explanation of the extensions:certificatePolicies:policyQualifiers:qualifier:userNotice field in the certificate profile resulting from combining change 450 with change 445.13.

• Expanded the description of the extensions:basicConstraints field in the certificate profile.

• Editorial changes to requirement 9.6.1-pkio127.

1.2.2 Relevant dates

1.3 PKI participants

1.3.1 Certification authorities

In this document the distinction is made between the term Certification Authority (CA) and Trust Service Provider. In international usage, "CA" is an umbrella term that refers to all entities authorized to issue, manage, revoke, and renew certificates. This can apply to the actual CA certificate as well as the organization. In this CP, the organization which holds a CA is refered to as a TSP. The term CA is used to refer to the infrastructure and keymaterial from which a TSP issues and signs certificates. This CP covers all certificates issued and signed by the following CAs hereinafter referred to as TSPs.

1.3.2 Registration authorities

Refer to Programme of Requirements part 3 Basic Requirements.

1.3.3 Subscribers

Refer to Programme of Requirements part 3 Basic Requirements.

1.3.4 Relying parties

Refer to Programme of Requirements part 3 Basic Requirements.

1.3.5 Other participants

Refer to Programme of Requirements part 3 Basic Requirements.

1.4 Certificate usage

1.4.1 Appropiate certificate uses

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

[OID 2.16.528.1.1003.1.2.5.4]

Authenticity certificates, issued under this CP, can be used to identify and authenticate, by electronic means, the service that is part of the organizational entity, that is responsible for the relevant service. Issuance of code signing certificates by means of which the integrity and authenticity of software can be safeguarded by a digital signature being placed are NOT allowed under this CP.

Under this OID OCSP responder certificates may be issued for use within the domain Organisation Services. Said certificates can be used to sign OCSP responses for use in the verification of the validity of the end user certificate. More information can be obtained in appendix A of the base requirements.

[OID 2.16.528.1.1003.1.2.5.5]

Confidentiality certificates, issued under this CP, can be used to protect the confidentiality of data that is exchanged and/or stored in an electronic format.

[OID 2.16.528.1.1003.1.2.5.7]

Seal certificates, issued under this CP, can be used to verify electronic seals.

1.4.2 Prohibited certificate uses

Refer to Programme of Requirements part 3 Basic Requirements.

1.5 Policy administration

1.5.1 Organization administering the document

The Ministry of Interior and Kingdom Relations (BZK) is responsible for this CPS. BZK has delegated this responsibility to Logius, including approval of changes of this document.

1.5.2 Contact person

Policy Authority PKIoverheid
Wilhelmina van Pruisenweg 52
Postbus 96810
2509 JE DEN HAAG
http://www.logius.nl/pkioverheid
servicecentrum@logius.nl

1.5.3 Person determining CPS suitability for the policy

The Policy Authority PKIoverheid (PA) determines the suitability of CPSs published as a result of this CP.

1.5.4 CP approval procedures

The PA PKIoverheid reserves the right to amend this CP. Changes are applicable from the date that is listed in section 1.2.2. Relevant dates. The management of Logius is responsible for following the procedures as listed in section 9.12 Amendments and final approval of this CP.

1.6 Definitions and acronyms

1.6.1 Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in these Requirements MUST be interpreted in accordance with RFC 2119.

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

Refer to Programme of Requirements part 3 Basic Requirements.

2.1 Repositories

Refer to Programme of Requirements part 3 Basic Requirements.

2.2 Publication of certification information

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

2.2-pkio191 —

2.2-pkio3 —

2.3 Time or frequency of publication

Refer to Programme of Requirements part 3 Basic Requirements.

2.4 Access controls on repositories

Refer to Programme of Requirements part 3 Basic Requirements.

3. IDENTIFICATION AND AUTHENTICATION

Refer to Programme of Requirements part 3 Basic Requirements.

3.1 Naming

Refer to Programme of Requirements part 3 Basic Requirements.

3.1.1 Types of names

Refer to Programme of Requirements part 3 Basic Requirements.

3.1.2 Need for names to be meaningful

Refer to Programme of Requirements part 3 Basic Requirements.

3.1.3 Anonymity or pseudonymity of subscribers

Refer to Programme of Requirements part 3 Basic Requirements.

3.1.4 Rules for interpreting various name forms

Refer to Programme of Requirements part 3 Basic Requirements.

3.1.5 Uniqueness of names

Refer to Programme of Requirements part 3 Basic Requirements.

3.1.6 Recognition, authentication, and role of trademarks

Refer to Programme of Requirements part 3 Basic Requirements.

3.2 Initial identity validation

Refer to Programme of Requirements part 3 Basic Requirements.

3.2.1 Method to prove possession of private key

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

3.2.1-pkio13 —

+————-+——————————————————————————————————————————————————————————-+ | Description | The TSP is responsible for ensuring that the subscriber supplies the certificate signing request (CSR) securely. The secure delivery must take place in the following manner: | | | | | | - the entry of the CSR on the TSP's application developed especially for that purpose, using an SSL connection with a PKIoverheid SSL certificate or similar or; | | | | | | - the entry of the CSR on the HTTPS website of the TSP that uses a PKIoverheid SSL certificate or similar or; | | | | | | - sending the CSR by e-mail, along with a qualified electronic signature of the certificate manager that uses a PKIoverheid qualified certificate or similar or; | | | | | | - entering or sending a CSR in a way that is at least equivalent to the aforementioned ways. |

+=============+===============================================================================================================================================================================+ | Comment | - | +————-+——————————————————————————————————————————————————————————-+

3.2.2 Authentication of organization identity

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

3.2.2-pkio144 —

3.2.2-pkio186 —

3.2.2-pkio4 —

3.2.3 Authentication of individual identity

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

3.2.3-pkio169 —

3.2.3-pkio22 —

3.2.3-pkio24 —

3.2.3-pkio26 —

+————-+———————————————————————————————————————————————————————————————————————————————————+ | Description | The certificate manager is a person whose identity has to be established in conjunction with an organizational entity. Proof has to be submitted of: | | | | | | - full name, including surname, first name, initials or other first (names) (if applicable) and surname prefixes (if applicable); | | | | | | - date of birth and place of birth, a nationally applicable registration number, or other characteristics of the certificate manager that can be used in order to, as far as possible, distinguish this person from other persons with the same name; | | | | | | - proof that the certificate manager is entitled to receive a certificate for a certificate holder on behalf of the legal personality or other organizational entity. |

+=============+=========================================================================================================================================================================================================================================================+ | Comment | - | +————-+———————————————————————————————————————————————————————————————————————————————————+

3.2.4 Non-verified subscriber information

Refer to Programme of Requirements part 3 Basic Requirements.

3.2.5 Validation of authority

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

3.2.5-pkio30 —

+————-+———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————–+ | Description | The TSP has to verify that: | | | | | | - the proof that the certificate holder is authorized to receive a certificate on behalf of the subscriber, is authentic; | | | | | | - the certificate manager has received permission from the subscriber to perform the actions that he has been asked to perform (if the certificate manager performs the registration process). |

+=============+===========================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+ | Comment | The "certificate manager" who takes over those actions from the certificate holder does not necessarily have to be the same person as the system administrator or personnel officer. Also the knowledge of the activation data of the key material (for example PIN) can be shared by various people if the organization of the certificate management requires that. However, it is recommended that as few people as possible have knowledge of the PIN. It also would be wise to take measures that limit access to the PIN. An example of this is placing the PIN in a safe to which only authorized persons can gain access in certain situations. | +————-+———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————–+

3.2.5-pkio33 —

3.2.6 Criteria for interoperation

Refer to Programme of Requirements part 3 Basic Requirements.

3.3 Identification and authentication for re-key requests

Refer to Programme of Requirements part 3 Basic Requirements.

3.3.1 Identification and authentication for routine re-key

Refer to Programme of Requirements part 3 Basic Requirements.

3.3.2 Identification and authentication for re-key after revocation

Refer to Programme of Requirements part 3 Basic Requirements.

3.4 Identification and authentication for revocation request

Refer to Programme of Requirements part 3 Basic Requirements.

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

Refer to Programme of Requirements part 3 Basic Requirements.

4.1 Certificate Application

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

4.1-pkio47 —

4.1.1 Who can submit a certificate application

Refer to Programme of Requirements part 3 Basic Requirements.

4.1.2 Enrollment process and responsibilities

Refer to Programme of Requirements part 3 Basic Requirements.

4.2 Certificate application processing

Refer to Programme of Requirements part 3 Basic Requirements.

4.2.1 Performing identification and authentication functions

Refer to Programme of Requirements part 3 Basic Requirements.

4.2.2 Approval or rejection of certificate applications

Refer to Programme of Requirements part 3 Basic Requirements.

4.2.3 Time to process certificate applications

Refer to Programme of Requirements part 3 Basic Requirements.

4.3 Certificate issuance

Refer to Programme of Requirements part 3 Basic Requirements.

4.3.1 CA actions during certificate issuance

Refer to Programme of Requirements part 3 Basic Requirements.

4.3.2 Notification to subscriber by the CA of issuance of Certificate

Refer to Programme of Requirements part 3 Basic Requirements.

4.4 Certificate acceptance

Refer to Programme of Requirements part 3 Basic Requirements.

4.4.1 Conduct constituting certificate acceptance

Refer to Programme of Requirements part 3 Basic Requirements.

4.4.2 Publication of the certificate by the CA

Refer to Programme of Requirements part 3 Basic Requirements.

4.4.3 Notification of certificate issuance by the CA to other Entities

Refer to Programme of Requirements part 3 Basic Requirements.

4.5 Key pair and certificate usage

Refer to Programme of Requirements part 3 Basic Requirements.

4.5.1 Subscriber private key and certificate usage

Refer to Programme of Requirements part 3 Basic Requirements.

4.5.2 Relying party public key and certificate usage

Refer to Programme of Requirements part 3 Basic Requirements.

4.6 Certificate renewal

Refer to Programme of Requirements part 3 Basic Requirements.

4.6.1 Circumstance for certificate renewal

Refer to Programme of Requirements part 3 Basic Requirements.

4.6.2 Who may request renewal

Refer to Programme of Requirements part 3 Basic Requirements.

4.6.3 Processing certificate renewal requests

Refer to Programme of Requirements part 3 Basic Requirements.

4.6.4 Notification of new certificate issuance to subscriber

Refer to Programme of Requirements part 3 Basic Requirements.

4.6.5 Conduct constituting acceptance of a renewal certificate

Refer to Programme of Requirements part 3 Basic Requirements.

4.6.6 Publication of the renewal certificate by the CA

Refer to Programme of Requirements part 3 Basic Requirements.

4.6.7 Notification of certificate issuance by the CA to other entities

Refer to Programme of Requirements part 3 Basic Requirements.

4.7 Certificate re-key

Refer to Programme of Requirements part 3 Basic Requirements.

4.7.1 Circumstance for certificate re-key

Refer to Programme of Requirements part 3 Basic Requirements.

4.7.2 Who may request certification of a new public key

Refer to Programme of Requirements part 3 Basic Requirements.

4.7.3 Processing certificate re-keying requests

Refer to Programme of Requirements part 3 Basic Requirements.

4.7.4 Notification of new certificate issuance to subscriber

Refer to Programme of Requirements part 3 Basic Requirements.

4.7.5 Conduct constituting acceptance of a re-keyed certificate

Refer to Programme of Requirements part 3 Basic Requirements.

4.7.6 Publication of the re-keyed certificate by the CA

Refer to Programme of Requirements part 3 Basic Requirements.

4.7.7 Notification of certificate issuance by the CA to other entities

Refer to Programme of Requirements part 3 Basic Requirements.

4.8 Certificate modification

Refer to Programme of Requirements part 3 Basic Requirements.

4.8.1 Circumstance for certificate modification

Refer to Programme of Requirements part 3 Basic Requirements.

4.8.2 Who may request certificate modification

Refer to Programme of Requirements part 3 Basic Requirements.

4.8.3 Processing certificate modification requests

Refer to Programme of Requirements part 3 Basic Requirements.

4.8.4 Notification of new certificate issuance to subscriber

Refer to Programme of Requirements part 3 Basic Requirements.

4.8.5 Conduct constituting acceptance of modified certificate

Refer to Programme of Requirements part 3 Basic Requirements.

4.8.6 Publication of the modified certificate by the CA

Refer to Programme of Requirements part 3 Basic Requirements.

4.8.7 Notification of certificate issuance by the CA to other entities

Refer to Programme of Requirements part 3 Basic Requirements.

4.9 Certificate revocation and suspension

Refer to Programme of Requirements part 3 Basic Requirements.

4.9.1 Circumstances for revocation

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

4.9.1-pkio192 —

+————-+—————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————–+ | Description | Certificates will be revoked when: | | | | | | - the subscriber indicates that the original request for a certificate was not allowed and the subscriber does not grant permission retroactively; | | | | | | - the TSP has sufficient evidence that the subscriber's private key (associated with the corresponding certificate) has been compromised or there is a suspicion of compromise, inherent security weakness, or that the certificate has been misused in another way . A key is considered compromised in the event of unauthorized access or suspected unauthorized access to the private key, lost or presumably lost private key, SSCD, SUD or QSCD, stolen or presumably stolen key, SSCD, SUD or QSCD or destroyed key, SSCD, SUD or QSCD if applicable; | | | | | | - a subscriber does not fulfill his obligations as set out in this CP or the corresponding CPS of the TSP or the agreement that the TSP has with the subscriber; | | | | | | - the TSP is informed or otherwise becomes aware of a material change in the information contained in the certificate. An example of this is: change of the name of the certificate holder (service); | | | | | | - the TSP determines that the certificate has not been issued in accordance with this CP or the associated CPS of the TSP or the agreement that the TSP has with the subscriber; | | | | | | - the TSP determines that information in the certificate is incorrect or misleading; | | | | | | - the TSP ceases its activities and the CRL and OCSP services are not continued by another TSP; | | | | | | - the PA of PKIoverheid determines that the technical content of the certificate entails an irresponsible risk for subscribers, relying parties and third parties (e.g. browser parties); | | | | | | - one of the events occurs, as described in chapter 6.2 of the Mozilla Root Store Policy. |

+=============+=================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+ | Comment | - | +————-+—————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————–+

4.9.2 Who can request revocation

Refer to Programme of Requirements part 3 Basic Requirements.

4.9.3 Procedure for revocation request

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

4.9.3-pkio57 —

4.9.4 Revocation request grace period

Refer to Programme of Requirements part 3 Basic Requirements.

4.9.5 Time within which CA must process the revocation request

Refer to Programme of Requirements part 3 Basic Requirements.

4.9.6 Revocation checking requirement for relying parties

Refer to Programme of Requirements part 3 Basic Requirements.

4.9.7 CRL issuance frequency (if applicable)

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

4.9.7-pkio65 —

4.9.8 Maximum latency for CRLs (if applicable)

Refer to Programme of Requirements part 3 Basic Requirements.

4.9.9 On-line revocation/status checking availability

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

4.9.9-pkio66 —

4.9.9-pkio67 —

4.9.9-pkio70 —

4.9.9-pkio71 —

4.9.10 On-line revocation checking requirements

Refer to Programme of Requirements part 3 Basic Requirements.

4.9.11 Other forms of revocation advertisements available

Refer to Programme of Requirements part 3 Basic Requirements.

4.9.12 Special requirements related to key compromise

Refer to Programme of Requirements part 3 Basic Requirements.

4.9.13 Circumstances for suspension

Refer to Programme of Requirements part 3 Basic Requirements.

4.9.14 Who can request suspension

Refer to Programme of Requirements part 3 Basic Requirements.

4.9.15 Procedure for suspension request

Refer to Programme of Requirements part 3 Basic Requirements.

4.9.16 Limits on suspension period

Refer to Programme of Requirements part 3 Basic Requirements.

4.10 Certificate status services

Refer to Programme of Requirements part 3 Basic Requirements.

4.10.1 Operational characteristics

Refer to Programme of Requirements part 3 Basic Requirements.

4.10.2 Service availability

Refer to Programme of Requirements part 3 Basic Requirements.

4.10.3 Optional features

Refer to Programme of Requirements part 3 Basic Requirements.

4.11 End of subscription

Refer to Programme of Requirements part 3 Basic Requirements.

4.12 Key escrow and recovery

Refer to Programme of Requirements part 3 Basic Requirements.

4.12.1 Key escrow and recovery policy and practices

Refer to Programme of Requirements part 3 Basic Requirements.

4.12.2 Session key encapsulation and recovery policy and practices

Refer to Programme of Requirements part 3 Basic Requirements.

5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

Refer to Programme of Requirements part 3 Basic Requirements.

5.1 Physical controls

Refer to Programme of Requirements part 3 Basic Requirements.

5.1.1 Site location and construction

Refer to Programme of Requirements part 3 Basic Requirements.

5.1.2 Physical access

Refer to Programme of Requirements part 3 Basic Requirements.

5.1.3 Power and air conditioning

Refer to Programme of Requirements part 3 Basic Requirements.

5.1.4 Water exposures

Refer to Programme of Requirements part 3 Basic Requirements.

5.1.5 Fire prevention and protection

Refer to Programme of Requirements part 3 Basic Requirements.

5.1.6 Media storage

Refer to Programme of Requirements part 3 Basic Requirements.

5.1.7 Waste disposal

Refer to Programme of Requirements part 3 Basic Requirements.

5.1.8 Off-site backup

Refer to Programme of Requirements part 3 Basic Requirements.

5.2 Procedural controls

Refer to Programme of Requirements part 3 Basic Requirements.

5.2.1 Trusted roles

Refer to Programme of Requirements part 3 Basic Requirements.

5.2.2 Number of persons required per task

Refer to Programme of Requirements part 3 Basic Requirements.

5.2.3 Identification and authentication for each role

Refer to Programme of Requirements part 3 Basic Requirements.

5.2.4 Roles requiring separation of duties

Refer to Programme of Requirements part 3 Basic Requirements.

5.3 Personnel controls

Refer to Programme of Requirements part 3 Basic Requirements.

5.3.1 Qualifications, experience, and clearance requirements

Refer to Programme of Requirements part 3 Basic Requirements.

5.3.2 Background check procedures

Refer to Programme of Requirements part 3 Basic Requirements.

5.3.3 Training requirements

Refer to Programme of Requirements part 3 Basic Requirements.

5.3.4 Retraining frequency and requirements

Refer to Programme of Requirements part 3 Basic Requirements.

5.3.5 Job rotation frequency and sequence

Refer to Programme of Requirements part 3 Basic Requirements.

5.3.6 Sanctions for unauthorized actions

Refer to Programme of Requirements part 3 Basic Requirements.

5.3.7 Independent contractor requirements

Refer to Programme of Requirements part 3 Basic Requirements.

5.3.8 Documentation supplied to personnel

Refer to Programme of Requirements part 3 Basic Requirements.

5.4 Audit logging procedures

Refer to Programme of Requirements part 3 Basic Requirements.

5.4.1 Types of events recorded

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

5.4.1-pkio80 —

+————-+————————————————————————–+ | Description | Logging has to take place on at least: | | | | | | - Routers, firewalls and network system components; | | | | | | - Database activities and events; | | | | | | - Transactions; | | | | | | - Operating systems; | | | | | | - Access control systems; | | | | | | - Mail servers. | | | | | | At the very least, the TSP has to log the following events: | | | | | | | | | | | | - CA key life cycle management; | | | | | | - Certificate life cycle management; | | | | | | - Threats and risks such as: | | | | | | - Successful and unsuccessful attacks on the PKI system; | | | | | | - Activities of staff on the PKI system; | | | | | | - Reading, writing and deleting data; | | | | | | - Profile changes (Access Management); | | | | | | - System failure, hardware failure and other abnormalities; | | | | | | - Firewall and router activities; | | | | | | - Entering and leaving the CA space. | | | | | | At the very least, the log files have to register the following: | | | | | | | | | | | | - Source addresses (IP addresses if available); | | | | | | - Destination addresses (IP addresses if available); | | | | | | - Time and date; | | | | | | - User IDs (if available); | | | | | | - Name of the incident; | | | | | | - Description of the incident. |

+=============+==========================================================================+ | Comment | Based on a risk analysis the TSP determines which data it should save. | +————-+————————————————————————–+

5.4.2 Frequency of processing log

Refer to Programme of Requirements part 3 Basic Requirements.

5.4.3 Retention period for audit log

Refer to Programme of Requirements part 3 Basic Requirements.

5.4.4 Protection of audit log

Refer to Programme of Requirements part 3 Basic Requirements.

5.4.5 Audit log backup procedures

Refer to Programme of Requirements part 3 Basic Requirements.

5.4.6 Audit collection system (internal vs. external)

Refer to Programme of Requirements part 3 Basic Requirements.

5.4.7 Notification to event-causing subject

Refer to Programme of Requirements part 3 Basic Requirements.

5.4.8 Vulnerability assessments

Refer to Programme of Requirements part 3 Basic Requirements.

5.5 Records archival

Refer to Programme of Requirements part 3 Basic Requirements.

5.5.1 Types of records archived

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

5.5.1-pkio82 —

5.5.2 Retention period for archive

Refer to Programme of Requirements part 3 Basic Requirements.

5.5.3 Protection of archive

Refer to Programme of Requirements part 3 Basic Requirements.

5.5.4 Archive backup procedures

Refer to Programme of Requirements part 3 Basic Requirements.

5.5.5 Requirements for time-stamping of records

Refer to Programme of Requirements part 3 Basic Requirements.

5.5.6 Archive collection system (internal or external)

Refer to Programme of Requirements part 3 Basic Requirements.

5.5.7 Procedures to obtain and verify archive information

Refer to Programme of Requirements part 3 Basic Requirements.

5.6 Key changeover

Refer to Programme of Requirements part 3 Basic Requirements.

5.7 Compromise and disaster recovery

Refer to Programme of Requirements part 3 Basic Requirements.

5.7.1 Incident and compromise handling procedures

Refer to Programme of Requirements part 3 Basic Requirements.

5.7.2 Computing resources, software, and_or data are corrupted

Refer to Programme of Requirements part 3 Basic Requirements.

5.7.3 Entity private key compromise procedures

Refer to Programme of Requirements part 3 Basic Requirements.

5.7.4 Business continuity capabilities after a disaster

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

5.7.4-pkio86 —

+————-+———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————-+ | Description | The TSP has to draw up a business continuity plan (BCP) for, at the very least, the core services dissemination service, revocation management service and revocation status service, the aim being, in the event of a security breach or emergency, to inform, reasonably protect and to continue the TSP services for subscribers, relying parties and third parties (including browser parties). The TSP has to test, assess and update the BCP annually. At the very least, the BCP has to describe the following processes: | | | | | | - Requirements relating to entry into force; | | | | | | - Emergency procedure/fall-back procedure; | | | | | | - Requirements relating to restarting TSP services; | | | | | | - Maintenance schedule and test plan that cover the annual testing, assessment and update of the BCP; | | | | | | - Provisions in respect of highlighting the importance of business continuity; | | | | | | - Tasks, responsibilities and competences of the involved agents; | | | | | | - Intended Recovery Time or Recovery Time Objective (RTO); | | | | | | - Recording the frequency of back-ups of critical business information and software; | | | | | | - Recording the distance of the fall-back facility to the TSP's main site; and | | | | | | - Recording the procedures for securing the facility during the period following a security breach or emergency and for the organization of a secure environment at the main site or fall-back facility. |

+=============+==================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+ | Comment | - | +————-+———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————-+

5.8 CA or RA termination

Refer to Programme of Requirements part 3 Basic Requirements.

6. TECHNICAL SECURITY CONTROLS

Refer to Programme of Requirements part 3 Basic Requirements.

6.1 Key pair generation and installation

Refer to Programme of Requirements part 3 Basic Requirements.

6.1.1 Key pair generation

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

6.1.1-pkio153 —

+————-+————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————–+ | Description | Subject key generation of a qualified digital seal certificate for the use of mass automated signing of standardised data is allowed in ETSI 319 411-2. ETSI does not stipulate the applicable security requirements. Subject key generation within PKIoverheid is possible under the following conditions: | | | | | | The contract between the TSP and the subscriber contains an assertion that the subscriber will generate, store and use the private key on a qualified device for electronic signatures – such as a HSM – which meets the requirements of {7} CWA 14169 Secure signature-creation devices or EN 419 211 for Qualified signature-creation devices "EAL 4+" or equivalent security criteria such as FIPS 140-2 level 3. | | | | | | The subscriber shall hand over evidence to this effect with the certificate request by submitting the certification of the secure device and, if applicable, a screenshot of the settings of the secure device on FIPS140-2 level 3. | | | | | | - The contract between the TSP and the subscriber contains an assertion in which the subscriber states that the private key (and associated activation data, such as a PIN code) related to the public key is generated in the qualified device and is kept secret and protected in future. | | | | | | The subscriber shall hand over evidence to this effect of the PKI ceremony script which is used during the implementation of the qualified device for electronic signatures and the generation of the key pair. | | | | | | | | | | | | - The TSP is present during the PKI ceremony for the commissioning of the qualified device for electronic signatures and the generation of the key pair. This enables the TSP to check the effectiveness of the security measures. | | | | | | | | | | | | - During registration the Subscriber submits a written statement of demonstrably satisfying the requirements and/or conditions placed either on the use of the qualified device for electronic signatures, or by the certification of the device on the environment in which it is administrated and the administration itself. | | | | | | | | | | | | - The Subscriber submits a written statement that the certificate holder has explicitly mandated the system administrators of the qualified device for electronic signatures for the administration and that access to this device is always subject to dual control. |

+=============+==========================================================================================================================================================================================================================================================================================================================================================================================================================+ | Comment | If the de TSP generates the key pair and the certificate and distributes these to the subscriber on a secure device it is not necessary to be present at the ceremony. | +————-+————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————–+

6.1.1-pkio88 —

6.1.1-pkio89 —

6.1.1-pkio92 —

6.1.1-pkio93 —

+————-+————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————–+ | Description | Instead of the TSP generating the keys, the certificate manager MAY generate the keys of the services authenticity and encryption certificates in a SUD using PKCS#10 to deliver the CSR to the TSP for signing, under the following conditions: | | | | | | - The agreement between the TSP and the subscriber stipulates that the certificate manager generates, saves and uses the private key on a secure device that conforms to the requirements of CWA 14169 for a Secure signature-creation devices or EN 419 211 for Qualified signature-creation devices “EAL 4+" or comparable security criteria. | | | | | | With the request the subscriber must prove that the secure device used for key generation conforms to CWA 14169 for a Secure signature-creation devices or EN 419 211 for Qualified signature-creation devices EAL 4+"" or comparable security criteria. | | | | | | The TSP must then verify that the SUD in question conforms (comparable to”The subscriber MUST prove that the organization may use this name.”) | | | | | | | | | | | | - On registration the certificate manager must at least produce a written statement that measures have been taken in the environment of the system that generates/contains the keys. The measures must be of such quality that is practically impossible to steal or copy the keys unnoticed. | | | | | | The agreement between the subscriber and the TSP must stipulate that the TSP has the right to perform an audit on the measures taken (conform 6.2.11-pkio107) | | | | | | | | | | | | - The agreement between the subscriber and the TSP must contain the following condition. The subscriber must declare that the private key (and the corresponding access information such as a PIN code), relating to the public key in het SUD in question has, in an appropriate manner, been generated under the control of the certificate manager and will be kept secret and protected in the future. |

+=============+==============================================================================================================================================================================================================================================================================================================================================================================================================+ | Comment | - | +————-+————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————–+

6.1.2 Private key delivery to subscriber

Refer to Programme of Requirements part 3 Basic Requirements.

6.1.3 Public key delivery to certificate issuer

Refer to Programme of Requirements part 3 Basic Requirements.

6.1.4 CA public key delivery to relying parties

Refer to Programme of Requirements part 3 Basic Requirements.

6.1.5 Key sizes

Refer to Programme of Requirements part 3 Basic Requirements.

6.1.6 Public key parameters generation and quality checking

Refer to Programme of Requirements part 3 Basic Requirements.

6.1.7 Key usage purposes (as per X.509 v3 key usage field)

Refer to Programme of Requirements part 3 Basic Requirements.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

Refer to Programme of Requirements part 3 Basic Requirements.

6.2.1 Cryptographic module standards and controls

Refer to Programme of Requirements part 3 Basic Requirements.

6.2.2 Private key (n out of m) multi-person control

Refer to Programme of Requirements part 3 Basic Requirements.

6.2.3 Private key escrow

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

6.2.3-pkio100 —

6.2.3-pkio99 —

6.2.4 Private key backup

Refer to Programme of Requirements part 3 Basic Requirements.

6.2.5 Private key archival

Refer to Programme of Requirements part 3 Basic Requirements.

6.2.6 Private key transfer into or from a cryptographic module

Refer to Programme of Requirements part 3 Basic Requirements.

6.2.7 Private key storage on cryptographic module

Refer to Programme of Requirements part 3 Basic Requirements.

6.2.8 Method of activating private key

Refer to Programme of Requirements part 3 Basic Requirements.

6.2.9 Method of deactivating private key

Refer to Programme of Requirements part 3 Basic Requirements.

6.2.10 Method of destroying private key

Refer to Programme of Requirements part 3 Basic Requirements.

6.2.11 Cryptographic Module Rating

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

6.2.11-pkio105 —

6.2.11-pkio125 —

6.3 Other aspects of key pair management

Refer to Programme of Requirements part 3 Basic Requirements.

6.3.1 Public key archival

Refer to Programme of Requirements part 3 Basic Requirements.

6.3.2 Certificate operational periods and key pair usage periods

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

6.3.2-pkio109 —

6.4 Activation data

Refer to Programme of Requirements part 3 Basic Requirements.

6.4.1 Activation data generation and installation

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

6.4.1-pkio112 —

6.4.1-pkio113 —

6.4.2 Activation data protection

Refer to Programme of Requirements part 3 Basic Requirements.

6.4.3 Other aspects of activation data

Refer to Programme of Requirements part 3 Basic Requirements.

6.5 Computer security controls

Refer to Programme of Requirements part 3 Basic Requirements.

6.5.1 Specific computer security technical requirements

Refer to Programme of Requirements part 3 Basic Requirements.

6.5.2 Computer security rating

Refer to Programme of Requirements part 3 Basic Requirements.

6.6 Life cycle technical controls

Refer to Programme of Requirements part 3 Basic Requirements.

6.6.1 System development controls

Refer to Programme of Requirements part 3 Basic Requirements.

6.6.2 Security management controls

Refer to Programme of Requirements part 3 Basic Requirements.

6.6.3 Life cycle security controls

Refer to Programme of Requirements part 3 Basic Requirements.

6.7 Network security controls

Refer to Programme of Requirements part 3 Basic Requirements.

6.8 Time-stamping

Refer to Programme of Requirements part 3 Basic Requirements.

7. CERTIFICATE, CRL, AND OCSP PROFILES

Refer to Programme of Requirements part 3 Basic Requirements.

7.1 Certificate profile

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

7.1-pkio150 —

+————-+——————————————————————————————————————————————————————————————————————————————————————————-+ | Description | The certificate extension Extended Key Usage MUST be present, MUST NOT be marked “critical”, and MUST contain at least the following KeyPurposIds: | | | | | | For a services authentication certificate: | | | | | | - client Authentication =1.3.6.1.5.5.7.3.2 | | | | | | - document Signing =1.3.6.1.4.1.311.10.3.12 | | | | | | - emailProtection =1.3.6.1.5.5.7.3.4 | | | | | | For a services confidentiality certificate: | | | | | | | | | | | | - Encrypting File System =1.3.6.1.4.1.311.10.3.4 | | | | | | - emailProtection = 1.3.6.1.5.5.7.3.4 | | | | | | For a seal certificate | | | | | | | | | | | | - document Signing =1.3.6.1.4.1.311.10.3.12 | | | | | | - emailProtection = 1.3.6.1.5.5.7.3.4 | | | | | | The KeyPurposeId id-kp-serverAuth MUST NOT be present, the KeyPurposeId id-kp-codeSigning MUST NOT be present, the KeyPurposeId AnyextendedKeyusage MUST NOT be present and any KeyPurposeId solely intended to identify a service based on its FQDN MUST NOT be present. | | | | | | Specifically for G2 certificates any other KeyPurposeId defined in an open or accepted standard corresponding to the key usage as indicated by the KeyUsage extension MAY be present. In the G3 and following generations this extension MAY NOT be present. | | | | | | The above should take into account the EKUs included in the issuing TSP CA. If the issuing TSP CA is not provided with the mandatory EKUs stated above, these MAY NOT be included in the end-user certificate. |

+=============+===============================================================================================================================================================================================================================================================================+ | Comment | - | +————-+——————————————————————————————————————————————————————————————————————————————————————————-+

7.1-pkio173 —

+————-+———————————————————————————————————————————-+ | Description | The serial number of all end-user certificates must meet the following requirements: | | | | | | 1. The value of the serial number MUST NOT be 0 (zero); | | | | | | 2. The value of the serial number MUST NOT be negative; | | | | | | 3. The value of the serial number MUST be unique within the population of end-user certificates issued under an issuing TSP CA; | | | | | | 4. The serial number MUST have a minimum length of 96 bits (12 octets); | | | | | | 5. The value of the serial number MUST contain at least 64 bits of unpredictable random data; | | | | | | 6. Said random data MUST be generated by a Cryptographically Secure Pseudorandom Number Generator (CSPRNG); | | | | | | 7. The serial number MUST NOT be longer than 160 bits (20 octets). |

+=============+==================================================================================================================================+ | Comment | - | +————-+———————————————————————————————————————————-+

7.1.1 Version number(s)

Refer to Programme of Requirements part 3 Basic Requirements.

7.1.2 Certificate extensions

Refer to Programme of Requirements part 3 Basic Requirements.

7.1.3 Algorithm object identifiers

Refer to Programme of Requirements part 3 Basic Requirements.

7.1.4 Name forms

Refer to Programme of Requirements part 3 Basic Requirements.

7.1.5 Name constraints

Refer to Programme of Requirements part 3 Basic Requirements.

7.1.6 Certificate policy object identifier

Refer to Programme of Requirements part 3 Basic Requirements.

7.1.7 Usage of Policy Constraints extension

Refer to Programme of Requirements part 3 Basic Requirements.

7.1.8 Policy qualifiers syntax and semantics

Refer to Programme of Requirements part 3 Basic Requirements.

7.1.9 Processing semantics for the critical Certificate Policies extension

Refer to Programme of Requirements part 3 Basic Requirements.

7.2 CRL profile

Refer to Programme of Requirements part 3 Basic Requirements.

7.2.1 Version number(s)

Refer to Programme of Requirements part 3 Basic Requirements.

7.2.2 CRL and CRL entry extensions

Refer to Programme of Requirements part 3 Basic Requirements.

7.3 OCSP profile

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

7.3-pkio123 —

7.3.1 Version number(s)

Refer to Programme of Requirements part 3 Basic Requirements.

7.3.2 OCSP extensions

Refer to Programme of Requirements part 3 Basic Requirements.

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

Refer to Programme of Requirements part 3 Basic Requirements.

8.1 Frequency or circumstances of assessment

Refer to Programme of Requirements part 3 Basic Requirements.

8.2 Identity/qualifications of assessor

Refer to Programme of Requirements part 3 Basic Requirements.

8.3 Assessors relationship to assessed entity

Refer to Programme of Requirements part 3 Basic Requirements.

8.4 Topics covered by assessment

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

8.4-pkio195 —

+————-+————————————————————————————————————————————————————+ | Description | In addition to this PoR, issuing certificates SHALL undergo an audit in accordance with the following schemes: | | | | | | 1. ETSI EN 319 411-1 with policy NCP+ (ETSI CP OID 0.4.0.2042.1.2, mandating usage of SSCDs) for authenticity and confidentiality certificates, and | | | | | | 2. ETSI EN 319 411-2 with policy QCP-l-qscd (ETSI CP OID 0.4.0.194112.1.3, mandating usage of SSCDs) for non-repudiation certificates (eIDAS eSeals), and | | | | | | 3. CA/Browser Forum Network and Certificate System Security Requirements. |

+=============+============================================================================================================================================================+ | Comment | - | +————-+————————————————————————————————————————————————————+

8.4-pkio200 —

+————-+——————————————————————————————————————————————————–+ | Description | If the TSP issues or intends to issue qualified certificates under PKIoverheid, the following additional requirements SHALL apply: | | | | | | 1. the audit report states that the TSP meets the eIDAS (910/2014) regulation requirements, and | | | | | | 2. the issuing certificate with which the TSP wants to issue qualified certificates is on the Trusted Services List (TSL) of Agentschap Telecom (AT). |

+=============+========================================================================================================================================================+ | Comment | - | +————-+——————————————————————————————————————————————————–+

8.5 Actions taken as a result of deficiency

Refer to Programme of Requirements part 3 Basic Requirements.

8.6 Communication of results

Refer to Programme of Requirements part 3 Basic Requirements.

9. OTHER BUSINESS AND LEGAL MATTERS

Refer to Programme of Requirements part 3 Basic Requirements.

9.1 Fees

Refer to Programme of Requirements part 3 Basic Requirements.

9.1.1 Certificate issuance or renewal fees

Refer to Programme of Requirements part 3 Basic Requirements.

9.1.2 Certificate access fees

Refer to Programme of Requirements part 3 Basic Requirements.

9.1.3 Revocation or status information access fees

Refer to Programme of Requirements part 3 Basic Requirements.

9.1.4 Fees for other services

Refer to Programme of Requirements part 3 Basic Requirements.

9.1.5 Refund policy

Refer to Programme of Requirements part 3 Basic Requirements.

9.2 Financial responsibility

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

9.2-pkio124 —

9.2.1 Insurance coverage

Refer to Programme of Requirements part 3 Basic Requirements.

9.2.2 Other assets

Refer to Programme of Requirements part 3 Basic Requirements.

9.2.3 Insurance or warranty coverage for end-entities

Refer to Programme of Requirements part 3 Basic Requirements.

9.3 Confidentiality of business information

Refer to Programme of Requirements part 3 Basic Requirements.

9.3.1 Scope of confidential information

Refer to Programme of Requirements part 3 Basic Requirements.

9.3.2 Information not within the scope of confidential information

Refer to Programme of Requirements part 3 Basic Requirements.

9.3.3 Responsibility to protect confidential information

Refer to Programme of Requirements part 3 Basic Requirements.

9.4 Privacy of personal information

Refer to Programme of Requirements part 3 Basic Requirements.

9.4.1 Privacy plan

Refer to Programme of Requirements part 3 Basic Requirements.

9.4.2 Information treated as private

Refer to Programme of Requirements part 3 Basic Requirements.

9.4.3 Information not deemed private

Refer to Programme of Requirements part 3 Basic Requirements.

9.4.4 Responsibility to protect private information

Refer to Programme of Requirements part 3 Basic Requirements.

9.4.5 Notice and consent to use private information

Refer to Programme of Requirements part 3 Basic Requirements.

9.4.6 Disclosure pursuant to judicial or administrative process

Refer to Programme of Requirements part 3 Basic Requirements.

9.4.7 Other information disclosure circumstances

Refer to Programme of Requirements part 3 Basic Requirements.

9.5 Intellectual property rights

Refer to Programme of Requirements part 3 Basic Requirements.

9.6 Representations and warranties

Refer to Programme of Requirements part 3 Basic Requirements.

9.6.1 CA representations and warranties

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

9.6.1-pkio132 —

9.6.2 RA representations and warranties

Refer to Programme of Requirements part 3 Basic Requirements.

9.6.3 Subscriber representations and warranties

Refer to Programme of Requirements part 3 Basic Requirements.

9.6.4 Relying party representations and warranties

Refer to Programme of Requirements part 3 Basic Requirements.

9.6.5 Representations and warranties of other participants

Refer to Programme of Requirements part 3 Basic Requirements.

9.7 Disclaimers of warranties

Refer to Programme of Requirements part 3 Basic Requirements.

9.8 Limitations of liability

Refer to Programme of Requirements part 3 Basic Requirements.

Additional requirements:

9.8-pkio133 —

9.9 Indemnities

Refer to Programme of Requirements part 3 Basic Requirements.

9.10 Term and termination

Refer to Programme of Requirements part 3 Basic Requirements.

9.10.1 Term

Refer to Programme of Requirements part 3 Basic Requirements.

9.10.2 Termination

Refer to Programme of Requirements part 3 Basic Requirements.

9.10.3 Effect of termination and survival

Refer to Programme of Requirements part 3 Basic Requirements.

9.11 Individual notices and communications with participants

Refer to Programme of Requirements part 3 Basic Requirements.

9.12 Amendments

Refer to Programme of Requirements part 3 Basic Requirements.

9.12.1 Procedure for amendment

Refer to Programme of Requirements part 3 Basic Requirements.

9.12.2 Notification mechanism and period

Refer to Programme of Requirements part 3 Basic Requirements.

9.12.3 Circumstances under which OID must be changed

Refer to Programme of Requirements part 3 Basic Requirements.

9.13 Dispute resolution provisions

Refer to Programme of Requirements part 3 Basic Requirements.

9.14 Governing law

Refer to Programme of Requirements part 3 Basic Requirements.

9.15 Compliance with applicable law

Refer to Programme of Requirements part 3 Basic Requirements.

9.16 Miscellaneous provisions

Refer to Programme of Requirements part 3 Basic Requirements.

9.16.1 Entire agreement

Refer to Programme of Requirements part 3 Basic Requirements.

9.16.2 Assignment

Refer to Programme of Requirements part 3 Basic Requirements.

9.16.3 Severability

Refer to Programme of Requirements part 3 Basic Requirements.

9.16.4 Enforcement (attorneys' fees and waiver of rights)

Refer to Programme of Requirements part 3 Basic Requirements.

9.16.5 Force Majeure

Refer to Programme of Requirements part 3 Basic Requirements.

9.17 Other provisions

Refer to Programme of Requirements part 3 Basic Requirements.

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 Attributes

Profile of services certificates for the Organization Services 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.

• N: Is NOT ALLOWED.

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

For the extensions, fields/attributes are used that, in accordance with international standards, are critical, are marked in the 'Critical' column with 'yes' to show that the relevant attribute MUST be checked using a process by means of which a certificate is evaluated. Other fields/attributes are shown with 'no'.

Services certificates for authenticity and confidentiality

Basic attributes

Standard extensions

Private extension