RFC 3647

4.9.9 On-line revocation/status checking availability

PKIo

If the TSP supports the Online Certificate Status Protocol ( OCSP ), this must conform to IETF RFC 6960.

RFC 3647

4.9.9 On-line revocation/status checking availability

PKIo

To detail the provisions of IETF RFC 2560 , OCSP responses have to be signed digitally by either:

· the private ( CA ) key with which the certificate is signed of which the status is requested, or;

· a responder appointed by the TSP which holds an OCSP Signing certificate issued for this purpose by the TSP , or;

· a responder that holds an OCSP Signing certificate that falls under the hierarchy of the PKI for the government.

RFC 3647

4.9.9 On-line revocation/status checking availability

PKIo

If the TSP supports OCSP , the information that is provided through OCSP has to be at least as equally up-to-date and reliable as the information that is published by means of a CRL , during the validity of the certificate that is issued and furthermore up to at least six months after the time at which the validity of the certificate has expired or, if that time is earlier, after the time at which the validity is ended by revocation.

RFC 3647

4.9.9 On-line revocation/status checking availability

PKIo

If the TSP supports OCSP , the TSP has to update the OCSP service at least once every 4 calendar days. The maximum expiry term of the OCSP responses is 10 calendar days. In addition OCSP responses must contain the “nextUpdate” field in conformance to RFC 6960.

RFC 3647

4.9.9 On-line revocation/status checking availability

PKIo

If the TSP supports OCSP , the OCSP response must have a minimum validity of 8 hours and a maximum validity of 7 calendar days. The next update must be available no later than half of the validity of an OCSP response.

RFC 3647

5.4.1 Types of events recorded

PKIo

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 ID s (if available);

· Name of the incident;

· Description of the incident.

RFC 3647

5.5.1 Types of records that are archived

PKIo

The TSP MUST archive all information used to verify the identity of the subscriber, certificate manager and applicants of revocation requests. This information includes reference numbers of the documentation used for verification, including limitations concerning the validity.

RFC 3647

5.7.4 Business continuity capabilities after a disaster.

PKIo

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.

RFC 3647

6.1.1 Key pair generation for the certificate holders

PKIo

The keys of certificate holders (or data for creating electronic signatures) have to be generated using a device that fulfils the requirements mentioned in EN 419 211 for QSCD ’s or CEN Workshop Agreement on Secure Signature Creation Devices"> CWA 14169 for SSCD ’s (transitional permission regime) "Secure signature-creation devices " EAL 4+"" or comparable security criteria.

RFC 3647

6.1.1 Key pair generation for the certificate holders

PKIo

The algorithm and the length of the cryptographic keys used by the TSP for generating keys of certificate holders has to fulfil the requirements laid down in that respect in the list of cryptographic algorithms and key lengths as defined in ETSI TS 119 312.

RFC 3647

6.1.1 Key pair generation for the certificate holders

PKIo

The generation of key pairs the certificate holder's key by the TSP is not allowed

RFC 3647

6.1.1 Key pair generation for the certificate holders

PKIo

If the TSP generates the private key for the subscriber, this MUST be supplied encrypted to the subscriber to safeguard the integrity and confidentiality of the private key. The following measures must then be taken into account:

a. The TSP MUST generate the private key for the subscriber in the secured environment to which the PKIoverheid PoR and the corresponding audit apply;

b. Once the private key has been generated for the subscriber, it MUST be stored encrypted using a strong algorithm (in accordance with the requirements of ETSI TS 102 176) within the TSP 's secured environment;

c. When storing this key, the TSP MUST apply the P12 standard, where the privacy mode and the integrity mode are used. To this end, the TSP MAY encrypt the P12 file with a personal PKI certificate of the subscriber/certificate manager. If this is not available, the TSP MUST use a password supplied by the subscriber. This password MUST be supplied by the subscriber through the TSP 's website, for which an SSL / TLS connection is used, or via a similar procedure which guarantees the same trustworthiness and security;

d. If a password is used to encrypt the P12 , this password has to contain at least 8 positions including at least one number and two special characters;

e. The TSP MAY NEVER send the password that is used to encrypt/decrypt the P12 in cleartext over a network or store it on a server. The password MUST be encrypted using a strong algorithm (in accordance with the requirements of ETSI TS 119 312);

f. The P12 file MUST be sent to the subscriber over an SSL / TLS secured network, or be supplied out-of-band on a data carrier ( e.g. USB stick or CD-Rom ).

g. If the P12 is supplied out-of-band, this must be additionally encrypted with a key other than the P12 file. In addition, the P12 MUST be delivered to the subscriber using a certified courier, or by a representative of the TSP in a seal bag. The courier must be certified in accordance with the requirements dictated in part 2 under paragraph 2.2 for the specific service applicable here.

h. If the P12 file is sent over a SSL / TLS secured network the TSP MUST ensure that the P12 file is successfully downloaded no more than once. Access to the P12 file when transferring via SSL / TLS has to be blocked after three attempts.

RFC 3647

6.1.1 Key pair generation for the certificate holders

PKIo

A TSP within PKIoverheid is not allowed to issue code signing certificates.

RFC 3647

6.1.2 Private key and SSCD or QSCD delivery to certificate holder

PKIo

[OID 2.16.528.1.1003.1.2.2.2 and 2.16.528.1.1003.1.2.5.2],

[OID 2.16.528.1.1003.1.2.2.1 and 2.16.528.1.1003.1.2.5.1] and

[OID 2.16.528.1.1003.1.2.3.2 and 2.16.528.1.1003.1.2.3.1].

The certificate holder's private key has to be delivered to the certificate holder, if required through the subscriber, in a manner such that the secrecy and the integrity of the key is not compromised and, once delivered to the certificate holder, the private key can be maintained under the certificate holder’s sole control.

RFC 3647

6.2.3 Private key escrow of certificate holder key

PKIo

The authorized persons who can gain access to the private key of the confidentiality certificate held in Escrow by the TSP (if applicable), have to identify themselves using the valid documents listed in article 1 of the Compulsory Identification Act (Wet op de identificatieplicht), or a valid qualified certificate (limited to a PKIoverheid signature certificate or equivalent).

RFC 3647

6.2.3 Private key escrow of certificate holder key

PKIo

The TSP has to describe in the CPS which parties can have access to the private key of the confidentiality certificate held in Escrow and under which conditions.

RFC 3647

6.2.3 Private key escrow of certificate holder key

PKIo

If the TSP keeps the private key of the confidentiality certificate in Escrow, the TSP has to guarantee that this private key is kept secret and only made available to appropriately authorized persons.

RFC 3647

6.2.11 Cryptographic module rating

PKIo

Secure devices issued or recommended by the TSP for creating electronic signatures ( SSCD s or QSCD s) have to fulfil the requirements laid down in document CEN Workshop Agreement on Secure Signature Creation Devices"> CWA 14169 " Secure signature-creation devices or EN 419 211 for Qualified signature-creation devices " EAL 4+"" and the requirements outlined in or pursuant to the Electronic Signatures Decree article 5, parts a, b, c and d.

RFC 3647

6.2.11 Cryptographic module rating

PKIo

Instead of demonstrating compliance with CEN Workshop Agreement on Secure Signature Creation Devices"> CWA 14169 (for SSCD ’s or SUD ’s) or EN 419 211 (for QSCD ’s) , TSP s can issue or recommend SSCD s, SUD s or QSCD s that are certified in line with a different protection profile against the Common Criteria ( ISO / IEC 15408 ) at level EAL 4+ or that have a comparable security level. This has to be established by a test laboratory that is accredited for performing Common Criteria evaluations.

RFC 3647

6.2.11 Cryptographic module rating

PKIo

The concurrence of SSCD s or QSCD s with the requirements outlined in PKIo requirement not 6.2.11-pkio104 has to have been ratified by a government body appointed to inspect the secure devices, for the creation of electronic signatures in accordance with the Dutch Telecommunications Act ( TW ) article 18.17, third paragraph. In this respect, also see the Ruling on Electronic Signatures, articles 4 and 5.

RFC 3647

6.2.11 Cryptographic module rating

PKIo

Instead of using a hardware-based SUD , the keys of a services certificate can be protected by software if compensating measures are taken in the system's environment that contains the keys. The compensating measures must be of such a quality that it is practically impossible to steal or copy the key unnoticed.

When registering, the manager of the services certificates that uses this option for software-based storage has, at the very least, to submit a written declaration to state that compensating measures have been taken that fulfil the condition stipulated to this end. The agreement between the subscriber and TSP must state that the TSP is entitled to check the measures that have been taken.

RFC 3647

6.2.11 Cryptographic module rating

PKIo

Secure devices issued or recommended by the TSP for storage of keys ( SUD s) have to fulfil the requirements laid down in document CEN Workshop Agreement on Secure Signature Creation Devices"> CWA 14169 "Secure signature-creation devices " EAL 4+""

RFC 3647

6.3.1 Public key archival

PKIo

[OID 2.16.528.1.1003.1.2.2.2, 2.16.528.1.1003.1.2.5.2 and 2.16.528.1.1003.1.2.3.2]

The signature certificate has to be saved during the term of validity and furthermore during a period of at least seven years after the date on which the validity of the certificate expired.

RFC 3647

6.3.2 Certificate operational periods and key pair usage periods

PKIo

Private keys that are used by a certificate holder and issued under the responsibility of this CP must not be used for more than five years. The certificates, which are issued under the responsibility of this CP , must not be valid for more than five years.

RFC 3647

6.3.2 Certificate operational periods and key pair usage periods

PKIo

Private keys that are used by a certificate holder and issued under the responsibility of this CP must not be used for more than ten years. The certificates, which are issued under the responsibility of this CP , must not be valid for more than ten years.

RFC 3647

6.4.1 Activation data generation and installation

PKIo

The TSP attaches activation data to the use of a SUD , SSCD or QSCD , to protect the private keys of the certificate holders.

RFC 3647

6.4.1 Activation data generation and installation

PKIo

An unlocking code can only be used if the TSP can guarantee that, at the very least, the security requirements are fulfilled that are laid down in respect of the use of the activation data.

RFC 3647

7.1 Certificate profile

PKIo

The certificate extension Extended Key Usage MUST be present, MUST NOT be marked “critical”, and MUST contain at least the following KeyPurposIds:

For an authenticity 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 signature certificate:

document Signing =1.3.6.1.4.1.311.10.3.12

emailProtection = 1.3.6.1.5.5.7.3.4

(mandatory for G3 , optional for G2 )

For an confidentiality certificate:

emailProtection =1.3.6.1.5.5.7.3.4

Encrypting File System =1.3.6.1.4.1.311.10.3.4

The KeyPurposeId id-kp-serverAuth MUST NOT be present and the KeyPurposeId id-kp-codeSigning 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.

RFC 3647

7.1 Certificate profile

PKIo

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

For a services confidentiality certificate:

emailProtection =1.3.6.1.5.5.7.3.4

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.

RFC 3647

7.1 Certificate profile

PKIo

The certificate extension Extended Key Usage MUST be present, MUST NOT be marked “critical”, and MUST contain at least the following KeyPurposIds:

For an Autonomous Devices – authenticity certificate:

Client Authentication =1.3.6.1.5.5.7.3.2

For an Autonomous Devices – confidentiality certificate:

emailProtection =1.3.6.1.5.5.7.3.4

Encrypting File System =1.3.6.1.4.1.311.10.3.4

For an Autonomous Devices – combination 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

Encrypting File System =1.3.6.1.4.1.311.10.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.

RFC 3647

PKIo

The Subject.CommonName field (if included) MUST contain a FQDN (Fully Qualified Domain Name). An FQDN MUST also appear in the SubjectAltName.DNsName field. An IP address MUST also appear in the SubjectAltName.iPAdress field.

A server certificate MAY contain multiple FQDNs from different domains on condition that these domains are registered in the name of the same subscriber or is authorization by the same subscriber.

This means that a TSP cannot combine FQDNs in one certificate that are both from different domains and are registered in the name of different owners.

The following is NOT allowed to be included in the Subject.Commonname field, SubjectAltName.iPAdress or the SubjectAltName.DNname field

- wildcard FQDNs

- local domain names,

- private IP addresses

- internationalized domain names ( IDN s)

- null characters \ 0

- generic TopLevel Domain ( gTLD )

- Country code TopLevelDomein ( ccTLD )

RFC 3647

PKIo

The Subject.CommonName field MUST contain a FQDN (Fully Qualified Domain Name). An FQDN MUST also appear in the SubjectAltName.DNsName field.

An Extended Validation certificate MAY contain several FQDNs. Every FQDN MUST fall under the same main domain. ( e.g. , www.logius.nl, application.logius.nl, secure.logius.nl etc.).

The following is NOT permitted to include in the Subject.Commonname field or the SubjectAltName.DNname field

- wildcard FQDNs

- local domain names,

- private IP addresses

- internationalized domain names ( IDN s)

- null characters \ 0

- generic TopLevel Domain ( gTLD )

- Country code TopLevelDomein ( ccTLD )

RFC 3647

PKIo

The Subject.CommonName SHOULD contain an FQDN (Fully Qualified Domain Name) or an IP address. An FQDN must also appear in the SubjectAltName.DNsName field. An IP address must also appear in the SubjectAltName.iPAdress field.

A server certificate may contain multiple FQDNs from different domains on condition that these domains are registered in the name of the same subscriber or are authorized by the same subscriber.

This means that a TSP cannot combine FQDNs in one certificate that are both from different domains and are registered in the name of different owners.

If it is not possible or desirable to include an FQDN in the subject.commonName field, but the field is necessary for the server to function properly, it is allowed to use the function of an organizational entity or the name with which the service, device or system is indicated.

The following is not permitted to be included in the Subject.Commonname field, SubjectAltName.iPadres or the SubjectAltName.DNname field

- wildcard FQDNs

- local domain names,

- private IP addresses

- internationalized domain names ( IDN s)

- null characters \ 0

- generic TopLevel Domain ( gTLD )

- Country code TopLevelDomein ( ccTLD )

RFC 3647

PKIo

From ETSI TS 119 312, the TSP MUST choose from 1 of the following options for the Signature field in a certificate:

· sha256WithRSAEncryption: 1.2.840.113549.1.1.11

( OBJECT IDENTIFIER ::= { iso(1)

member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 })

· ecdsa-with-SHA256: 1.2.840.10045.4.3.2

{OBJECT IDENTIFIER ::= { iso(1) member-body(2)

us(840)ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }})

· sha384WithRSAEncryption : 1.2.840.113549.1.1.12

{OBJECT IDENTIFIER ::= { iso(1)

member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 }

· ecdsa-with-SHA384:1.2.840.10045.4.3.3

{OBJECT IDENTIFIER ::= { iso(1) member-body(2)

us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }

RFC 3647

PKIo

The Authority Information Access field must contain the following entries:

Access Method = - Id-ad-ocsp (On-line Certificate Status Protocol - 1.3.6.1.5.5.7.48.1). This field must contain the URI where the OCSP responder can be found that is authorized by the issuing CA of the certificate to be checked;

Access Method = Certification Authority Issuer (1.3.6.1.5.5.7.48.2). This field must contain the URI where the certificate of the issuing CA can be found.

RFC 3647

PKIo

All end-user certificates must contain at least 64 bits of unpredictable random data generated by a Cryptographically Secure Pseudorandom Number Generator ( CSPRNG ).

RFC 3647

PKIo

All end-user certificates must contain at least 64 bits of unpredictable random data, preferably generated by a Cryptographically Secure Pseudo-random Number Generator ( CSPRNG ).

RFC 3647

7.3 OCSP profile

PKIo

If the TSP supports the Online Certificate Status Protocol ( OCSP ), the TSP has to use OCSP certificates and responses in accordance with the requirements laid down in this respect in appendix A of the Basic Requirements, " CRL and OCSP certificate Profiles for certificate status information ".

RFC 3647

8.6 Demonstration of BR conformity

The PA informs TSP s about relevant changes to the Baseline Requirements and / or the Extended Validation Guidelines. TSP s must prove that they comply with stated changes by submitting a signed statement from or on behalf of the authorized director to the PA before the effective date of the change in question. The PA provides a template for this.

If a TSP cannot comply on time or does not submit a signed declaration on time, the PA reserves the right to (temporarily) suspend certificate issuance at the relevant TSP until the TSP can (demonstrably) comply with the stated change.

RFC 3647

9.2. Financial Responsibility

PKIo

By means, for example, of insurance or its financial position, the TSP has to be able to cover third party recovery based on the types of liability mentioned in article 6:196b of the Civil Code (that relate to both direct and indirect damage) up to at least EUR 1,000,000 per annum.

RFC 3647

9.6.1 Representations and Warranties by TSP s

PKIo

In the agreement between the TSP and the subscriber, a clause (a clause as specified in article 6:253 of the Civil Code) will be included in which the TSP champions the interests of a third party relying on the certificate. This clause addresses a liability of the TSP in accordance with article 6:196b, first up to and including third paragraph, of the Civil Code, with the proviso that:

a. for "a qualified certificate specified in article 1.1, division ss Telecommunications Act": "an authenticity certificate" is read;

b. for "signatory": "certificate holder" is read;

c. for "electronic signatures": "authenticity properties" is read.

RFC 3647

9.6.1 Representations and Warranties by TSP s

PKIo

In the agreement between the TSP and the subscriber, a clause (a clause as specified in article 6:253 of the Civil Code) will be included in which the TSP champions the interests of a third party relying on the certificate. This clause addresses a liability of the TSP in accordance with article 6:196b, first up to and including third paragraph, of the Civil Code, with the proviso that:

a. for "a qualified certificate specified in article 1.1, division ss Telecommunications Act": "a server certificate" is read;

b. for "signatory": "certificate holder" is read;

c. for "creation of electronic signatures": "verification of authenticity features and creating encrypted data" is read;

d. For "verification of electronic signatures": "deciphering authentication features and encrypted data" is read.

RFC 3647

9.6.1 Representations and Warranties by TSP s

PKIo

In the agreement between the TSP and the subscriber, a clause (a clause as specified in article 6:253 of the Civil Code) will be included in which the TSP champions the interests of a third party relying on the certificate. This clause addresses a liability of the TSP in accordance with article 6:196b, first up to and including third paragraph, of the Civil Code, with the proviso that:

a. for "a qualified certificate specified in article 1.1, division ss Telecommunications Act": "a confidentiality certificate" is read;

b. for "signatory": "certificate holder" is read;

c. for "creation of electronic signatures": "creation of encrypted data" is read;

d. For "verification of electronic signatures": "decoding of encrypted data" is read.

RFC 3647

9.6.1 Representations and Warranties by TSP s

PKIo

[OID 2.16.528.1.1003.1.2.6.2]

In the agreement between the TSP and the subscriber, a clause (a clause as specified in article 6:253 of the Civil Code) will be included in which the TSP champions the interests of a third party relying on the certificate. This clause addresses a liability of the TSP in accordance with article 6:196b, first up to and including third paragraph, of the Civil Code, with the proviso that:

a. for "a qualified certificate specified in article 1.1, division ss Telecommunications Act": "a confidentiality certificate from the PKIoverheid Autonomous Devices domain" is read;

b. for "signatory": "certificate holder" is read;

c. for "creation of electronic signatures": "creation of encrypted data" is read;

d. For "verification of electronic signatures": "decoding of encrypted data" is read.

RFC 3647

9.6.1 Representations and Warranties by TSP s

PKIo

The TSP can include in a non-repudiation certificate restrictions with regard to the use of the certificate, provided that the restrictions are clear to third parties. The TSP is not liable for losses that results from the use of a signature certificate that is contrary to the provisions in accordance with the previous sentence listed therein.

RFC 3647

9.6.1 Representations and Warranties by TSP s

PKIo

The TSP excludes all liability for damages if the certificate is not used in accordance with the certificate use described in paragraph 1.4.

RFC 3647

9.8 Limitations of Liability

PKIo

Within the scope of certificates as mentioned in paragraph 1.4 in this CP the TSP is not allowed to place restrictions on the use of certificates.

RFC 3647

9.8 Limitations of Liability

PKIo

Within the scope of certificates as mentioned in paragraph 1.4 in this CP the TSP is not allowed to place restrictions on the use of EV SSL certificates.

RFC 3647

9.8 Limitations of Liability

PKIo

The TSP is allowed to place restrictions on the use of certificates within the scope of certificates as mentioned in paragraph 1.4 of the applicable PoR part for that type of certificate.

RFC 3647

9.17 Other Provisions

PKIo

The TSP has to be capable of issuing all types of personal certificates listed under [1.2] of the applicable PoR part for that type of certificate.

RFC 3647

9.17 Other Provisions

PKIo

The TSP has to be capable of issuing all types of services certificates listed under [1.2] of the applicable PoR part for that type of certificate.

RFC 3647

9.17 Other Provisions

PKIo

The TSP has to be capable of issuing at least one type of certificate listed under [1.2] of the applicable PoR part for that type of certificate.