Certification Practice Statement for ... - rdc.fina.hrrdc.fina.hr/RDC2015/FinaRDC2015-CPSWSA1-2-en.pdf · Updating referent list of Croatian legal regulations, enhancement to the

Certification Practice Statement for Certificates for Website Authentication

Classification: Designation: 75360601 Revision: 3-07/2018Page: 1/106

FINA CERTIFICATION PRACTICE STATEMENT

FOR CERTIFICATES FOR WEBSITE AUTHENTICATION

Version 1.2

Effective date: 01 August 2018 Document OID: 1.3.124.1104.5.0.5.2.1.2


Classification: Designation: 75360601 Revision: 3-07/2018 Page: 2/106

Document details

Document name: Certification Practice Statement for Certificates for Website Authentication

Document OID: 1.3.124.1104.5.0.5.2.1.2

Document Type: Certification Practice Statement (CPS)

Distribution Designation Public

Document Owner Financial Agency, Fina

Contact [email protected]

Amendment history

Version Date Reason for amendment

1.0 22/05/2017 Initial version

1.1 21/03/2018 Updating referent list of Croatian legal regulations, enhancement to the registration process by adding CAA record check statement, modified validity period of SSL Certificate Level 2 (OVCP) and correction of typographical errors.

1.2 27/07/2018

Adding descriptions of supported methods of validation of domain authorization or control and authentication for an IP address, updating referent list of Croatian legal regulations, adding a stipulation on the issuance of a certificate for legal persons with registered office location in the Republic of Croatia, adding the conformity declaration of the document with RFC 3647.

mailto:[email protected]



CONTENTS: REFERENT DOCUMENTED INFORMATION ......................................................................11

Core legislation .................................................................................................................11 Other legislation ................................................................................................................11 Standardization Documents ..............................................................................................11 Fina's Documents .............................................................................................................12

1 INTRODUCTION ...........................................................................................................13

1.1 Overview ................................................................................................................13 1.1.1 Scope and purpose ..........................................................................................13 1.1.2 Certificate Types ..............................................................................................14

1.2 Document name and identification ..........................................................................15 1.3 PKI participants ......................................................................................................15

1.3.1 Certification authorities.....................................................................................15 1.3.2 Registration authorities ....................................................................................16 1.3.3 Subscribers ......................................................................................................16 1.3.4 Relying parties .................................................................................................17 1.3.5 Other participants.............................................................................................17

1.4 Certificate usage .....................................................................................................17 1.4.1 Appropriate certificate uses ..............................................................................18 1.4.2 Prohibited certificate uses ................................................................................18

1.5 Policy administration ...............................................................................................18 1.5.1 Organization administering the document ........................................................18 1.5.2 Contact person ................................................................................................18 1.5.3 Person determining CPS suitability for the policy .............................................18 1.5.4 CPS approval procedures ................................................................................19

1.6 Definitions and acronyms ........................................................................................19 1.6.1 Definitions ........................................................................................................19 1.6.2 Abbreviations ...................................................................................................25

2 PUBLICATION AND REPOSITORY RESPONSIBILITIES ............................................27

2.1 Repositories ............................................................................................................27 2.2 Publication of certification information .....................................................................27

2.2.1 Repository Contents ........................................................................................27 2.2.2 Contents Publication and Repository Management Procedures .......................28

2.3 Time or frequency of publication .............................................................................29 2.4 Access controls on repositories ..............................................................................29

3 IDENTIFICATION AND AUTHENTICATION .................................................................30

3.1 Naming ...................................................................................................................30 3.1.1 Types of names ...............................................................................................30 3.1.2 Need for names to be meaningful ....................................................................30 3.1.3 Anonymity or pseudonymity of subscribers ......................................................30 3.1.4 Rules for interpreting various name forms ........................................................30 3.1.5 Uniqueness of names ......................................................................................31 3.1.6 Recognition, authentication, and role of trademarks .........................................31



3.2 Initial identity validation ...........................................................................................32

3.2.1 Method to prove possession of private key ......................................................32 3.2.2 Authentication of organization and domain identity ..........................................33 3.2.3 Authentication of individual identity ..................................................................36 3.2.4 Non-verified subscriber information ..................................................................38 3.2.5 Validation of authority ......................................................................................38 3.2.6 Criteria for interoperation .................................................................................39

3.3 Identification and authentication for re-key requests ...............................................39 3.3.1 Identification and authentication for routine re-key ...........................................40 3.3.2 Identification and authentication for re-key after revocation ..............................40 3.3.3 Identification and authentication for re-key after expiry ....................................40 3.3.4 Identification and authentication for certificate recovery ...................................40

3.4 Identification and authentication for revocation request...........................................40 4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS ..................................42

4.1 Certificate Application .............................................................................................42 4.1.1 Who can submit a certificate application ..........................................................42 4.1.2 Enrolment process and responsibilities ............................................................42

4.2 Certificate application processing ...........................................................................43 4.2.1 Performing identification and authentication functions ......................................43 4.2.2 Approval or rejection of certificate applications ................................................44 4.2.3 Time to process certificate applications ............................................................45

4.3 Certificate issuance ................................................................................................45 4.3.1 CA actions during certificate issuance ..............................................................45 4.3.2 Notification of certificate issuance by the CA to other entities...........................47

4.4 Certificate acceptance ............................................................................................47 4.4.1 Conduct constituting certificate acceptance .....................................................47 4.4.2 Publication of the certificate by the CA .............................................................47 4.4.3 Notification of certificate issuance by the CA to other entities...........................48

4.5 Key pair and certificate usage .................................................................................48 4.5.1 Subscriber private key and certificate usage ....................................................48 4.5.2 Relying party public key and certificate usage ..................................................48

4.6 Certificate renewal ..................................................................................................49 4.6.1 Circumstance for certificate renewal ................................................................49 4.6.2 Who may request renewal ...............................................................................49 4.6.3 Processing certificate renewal requests ...........................................................49 4.6.4 Notification of new certificate issuance to subscriber .......................................49 4.6.5 Conduct constituting acceptance of a renewal certificate .................................49 4.6.6 Publication of the renewal certificate by the CA ...............................................49 4.6.7 Notification of certificate issuance by the CA to other entities...........................50

4.7 Certificate re-key.....................................................................................................50 4.7.1 Circumstance for certificate re-key ...................................................................50 4.7.2 Who may request certification of a new public key ...........................................51 4.7.3 Processing certificate re-keying requests .........................................................51 4.7.4 Notification of new certificate issuance to subscriber .......................................51 4.7.5 Conduct constituting acceptance of a re-keyed certificate ................................51 4.7.6 Publication of the re-keyed certificate by the CA ..............................................52



4.7.7 Notification of certificate issuance by the CA to other entities...........................52

4.8 Certificate modification............................................................................................52 4.8.1 Circumstance for certificate modification ..........................................................52 4.8.2 Who may request certificate modification .........................................................52 4.8.3 Processing certificate modification requests .....................................................52 4.8.4 Notification of new certificate issuance to subscriber .......................................53 4.8.5 Conduct constituting acceptance of modified certificate ...................................53 4.8.6 Publication of the modified certificate by the CA ..............................................53 4.8.7 Notification of certificate issuance by the CA to other entities...........................53

4.9 Certificate revocation and suspension ....................................................................53 4.9.1 Circumstances for revocation ...........................................................................53 4.9.2 Who can request revocation ............................................................................54 4.9.3 Procedure for revocation request .....................................................................54 4.9.4 Revocation request grace period .....................................................................55 4.9.5 Time within which CA must process the revocation request .............................55 4.9.6 Revocation checking requirement for relying parties ........................................56 4.9.7 CRL issuance frequency ..................................................................................56 4.9.8 Maximum latency for CRLs ..............................................................................56 4.9.9 On-line revocation/status checking availability .................................................56 4.9.10 On-line revocation checking requirements .......................................................56 4.9.11 Other forms of revocation advertisements available .........................................57 4.9.12 Special requirements related to key compromise .............................................57 4.9.13 Circumstances for suspension .........................................................................57 4.9.14 Who can request suspension ...........................................................................57 4.9.15 Procedure for suspension request ...................................................................57 4.9.16 Limits on suspension period .............................................................................57

4.10 Certificate status services .......................................................................................57 4.10.1 Operational characteristics ...............................................................................57 4.10.2 Service availability ...........................................................................................58 4.10.3 Optional features..............................................................................................58

4.11 End of subscription .................................................................................................58 4.12 Key escrow and recovery ........................................................................................59

5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS ...................................60

5.1 Physical controls .....................................................................................................60 5.1.1 Site location and construction ..........................................................................60 5.1.2 Physical access ...............................................................................................60 5.1.3 Power and air conditioning ...............................................................................61 5.1.4 Water exposure ...............................................................................................61 5.1.5 Fire prevention and protection..........................................................................61 5.1.6 Media storage ..................................................................................................62 5.1.7 Waste disposal ................................................................................................62 5.1.8 Off-Site backup ................................................................................................62

5.2 Procedural controls .................................................................................................63 5.2.1 Trusted roles ....................................................................................................63 5.2.2 Number of persons required per task ...............................................................63 5.2.3 Identification and authentication for each role ..................................................63 5.2.4 Roles requiring separation of duties .................................................................64



5.3 Personnel controls ..................................................................................................65

5.3.1 Qualifications, experience, and clearance requirements ..................................65 5.3.2 Background check procedures .........................................................................65 5.3.3 Training requirements ......................................................................................65 5.3.4 Retraining frequency and requirements ...........................................................66 5.3.5 Job rotation frequency and sequence ..............................................................66 5.3.6 Sanctions for unauthorised actions ..................................................................66 5.3.7 Independent contractor requirements ...............................................................66 5.3.8 Documentation supplied to personnel ..............................................................66

5.4 Audit logging procedures ........................................................................................67 5.4.1 Types of events recorded .................................................................................67 5.4.2 Frequency of processing log ............................................................................67 5.4.3 Retention period for audit log ...........................................................................68 5.4.4 Protection of audit log ......................................................................................68 5.4.5 Audit log backup procedures ............................................................................68 5.4.6 Audit collection system (internal vs. external) ...................................................69 5.4.7 Notification to event-causing subject ................................................................69 5.4.8 Vulnerability assessments ................................................................................69

5.5 Records archival .....................................................................................................69 5.5.1 Types of records archived ................................................................................69 5.5.2 Retention period for archive .............................................................................70 5.5.3 Protection of archive ........................................................................................70 5.5.4 Archive backup procedures ..............................................................................71 5.5.5 Requirements for time-stamping of records......................................................71 5.5.6 Archive collection system (internal or external) ................................................71 5.5.7 Procedures to obtain and verify archive information .........................................71

5.6 Key changeover ......................................................................................................71 5.7 Compromise and disaster recovery ........................................................................72

5.7.1 Incident and compromise handling procedures ................................................72 5.7.2 Computing resources, software and/or data are corrupted ...............................73 5.7.3 Entity private key compromise procedures .......................................................73 5.7.4 Business continuity capabilities after a disaster ...............................................74

5.8 CA or RA termination ..............................................................................................74 6 TECHNICAL SECURITY CONTROLS ..........................................................................76

6.1 Key pair generation and installation ........................................................................76 6.1.1 Key pair generation ..........................................................................................76 6.1.2 Private key delivery to subscriber .....................................................................77 6.1.3 Public key delivery to certificate issuer .............................................................78 6.1.4 CA public key delivery to relying parties ...........................................................78 6.1.5 Key sizes .........................................................................................................78 6.1.6 Public key parameters generation and quality checking ...................................78 6.1.7 Key usage purposes (as per X.509 v3 key usage field) ....................................79

6.2 Private Key Protection and Cryptographic Module Engineering Controls ................79 6.2.1 Cryptographic module standards and controls .................................................79 6.2.2 Private key (n out of m) multi-person control ....................................................80 6.2.3 Private key escrow ...........................................................................................80 6.2.4 Private key backup ...........................................................................................80



6.2.5 Private key archival ..........................................................................................80 6.2.6 Private key transfer into or from a cryptographic module ..................................80 6.2.7 Private key storage on cryptographic module ...................................................81 6.2.8 Method of activating private key .......................................................................81 6.2.9 Method of deactivating private key ...................................................................81 6.2.10 Method of destroying private key .....................................................................82 6.2.11 Cryptographic Module Rating ...........................................................................83

6.3 Other aspects of key pair management ..................................................................83 6.3.1 Public key archival ...........................................................................................83 6.3.2 Certificate operational periods and key pair usage periods ..............................83

6.4 Activation data ........................................................................................................84 6.4.1 Activation data generation and installation .......................................................84 6.4.2 Activation data protection .................................................................................84 6.4.3 Other aspects of activation data .......................................................................84

6.5 Computer security controls .....................................................................................85 6.5.1 Specific computer security technical requirements ...........................................85 6.5.2 Computer security rating ..................................................................................86

6.6 Life cycle technical controls ....................................................................................86 6.6.1 System development controls ..........................................................................86 6.6.2 Security management controls .........................................................................86 6.6.3 Life cycle security controls ...............................................................................87

6.7 Network security controls ........................................................................................87 6.8 Time-stamping ........................................................................................................88

7 CERTIFICATE, CRL, AND OCSP PROFILES ...............................................................89

7.1 Certificate profile .....................................................................................................89 7.1.1 Version number(s) ...........................................................................................89 7.1.2 Certificate extensions .......................................................................................89 7.1.3 Algorithm object identifiers ...............................................................................89 7.1.4 Name forms .....................................................................................................89 7.1.5 Name constraints .............................................................................................90 7.1.6 Certificate policy object identifier ......................................................................90 7.1.7 Usage of Policy Constraints extension .............................................................90 7.1.8 Policy qualifiers syntax and semantics .............................................................90 7.1.9 Processing Semantics for the critical Certificate Policies extension .................90

7.2 CRL profile..............................................................................................................90 7.2.1 Version number(s) ...........................................................................................90 7.2.2 CRL and CRL entry extensions ........................................................................90

7.3 OCSP profile ...........................................................................................................91 7.3.1 Version number(s) ...........................................................................................91 7.3.2 OCSP extensions.............................................................................................91

8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS ..................................................92

8.1 Frequency or circumstances of assessment ...........................................................92 8.1.1 External Compliance Audit ...............................................................................92 8.1.2 Internal Compliance Audit ................................................................................92

8.2 Identity/qualifications of assessors ..........................................................................93



8.3 Assessor's relationship to assessed entity ..............................................................93 8.4 Topics covered by assessment ...............................................................................93 8.5 Actions taken as a result of deficiency ....................................................................94 8.6 Communication of results .......................................................................................94

9 OTHER BUSINESS AND LEGAL MATTERS ................................................................95

9.1 Fees .......................................................................................................................95 9.1.1 Certificate issuance or renewal fees.................................................................95 9.1.2 Certificate access fees .....................................................................................95 9.1.3 Revocation or status information access fees ..................................................95 9.1.4 Fees for other services.....................................................................................95 9.1.5 Refund policy ...................................................................................................95

9.2 Financial responsibility ............................................................................................96 9.2.1 Insurance coverage .........................................................................................96 9.2.2 Other assets ....................................................................................................96 9.2.3 Insurance or warranty coverage for end-entities ..............................................96

9.3 Confidentiality of Business information ...................................................................96 9.3.1 Scope of confidential information .....................................................................96 9.3.2 Information not within the scope of confidential information .............................96 9.3.3 Responsibility to protect confidential information ..............................................96

9.4 Privacy of personal information ...............................................................................97 9.4.1 Privacy plan .....................................................................................................97 9.4.2 Information treated as private...........................................................................97 9.4.3 Information not deemed private ........................................................................97 9.4.4 Responsibility to protect private information .....................................................97 9.4.5 Notice and consent to use private information ..................................................97 9.4.6 Disclosure pursuant to judicial or administrative process .................................97 9.4.7 Other information disclosure circumstances .....................................................98

9.5 Intellectual property rights .......................................................................................98 9.6 Representations and warranties .............................................................................98

9.6.1 CA representations and warranties ..................................................................98 9.6.2 RA representations and warranties ................................................................ 100 9.6.3 Subscriber representations and warranties .................................................... 100 9.6.4 Relying party representations and warranties ................................................ 101 9.6.5 Representations and warranties of other participants ..................................... 102

9.7 Disclaimer of warranties ........................................................................................ 102 9.8 Limitations of liability ............................................................................................. 103 9.9 Indemnities ........................................................................................................... 103 9.10 Term and termination ............................................................................................ 104

9.10.1 Term .............................................................................................................. 104 9.10.2 Termination .................................................................................................... 104 9.10.3 Effect of termination and survival ................................................................... 104

9.11 Individual notices and communication with participants ........................................ 104 9.12 Amendments ........................................................................................................ 105

9.12.1 Procedure for amendment ............................................................................. 105 9.12.2 Notification mechanism and period ................................................................ 105 9.12.3 Circumstances under which OID must be changed ........................................ 105



9.13 Dispute resolution provisions ................................................................................ 106 9.14 Governing law ....................................................................................................... 106 9.15 Compliance with applicable law ............................................................................ 106 9.16 Miscellaneous provisions ...................................................................................... 106



COPYRIGHT The Certification Policy is the property of Fina, administered by Fina PMA and subject to copyright in accordance with laws of the Republic of Croatia.



REFERENT DOCUMENTED INFORMATION

Core legislation [1] Regulation (EU) No 910/2014 of the European Parliament and of the Council

of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC

[2] Act Implementing Regulation (EU) no. 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Council Directive 1999/93 / EC (Croatian Official Gazette (hereinafter referred to as Official Gazette) 62/2017)

Other legislation [3] Act Implementing General Data Protection Regulation (Official Gazette

42/2018)

Standardization Documents [4] ISO/IEC 27001:2013 – Information technology – Security techniques –

Information security management [5] ISO/IEC 27002:2013 – Information technology – Security techniques – Code

of practice for information security management [6] ETSI EN 319 401 V2.1.1. (2016-02) – Electronic Signatures and

Infrastructures (ESI); General Policy Requirements for Trust Service Providers [7] ETSI EN 319 411-1 V1.1.1. (2016-02) – Electronic Signatures and

Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements

[8] ETSI EN 319 412-1 V1.1.1. (2016-02) – Electronic Signatures and Infrastructures (ESI);Certificate Profiles; Part 1: Overview and common data structures

[9] ETSI EN 319 412-3 V1.1.1. (2016-02) – Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 3: Certificate profile for certificates issued to Legal persons

[10] ETSI EN 319 412-4 V1.1.1. (2016-02) – Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 4: Certificate profile for web site certificates

[11] ETSI EN 319 403 V 2.2.2 (2015-08) - Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment - Requirements for conformity assessment bodies assessing Trust Service Providers

[12] ETSI TS 119 312 – Electronic Signatures and Infrastructures (ESI); Cryptographic Suites



[13] NIST FIPS PUB 140-1 (1994) – Security Requirements for Cryptographic

Modules [14] NIST FIPS PUB 140-2 (2001) – Security Requirements for Cryptographic

Modules [15] IETF RFC 3647 – Internet X.509 Public Key Infrastructure: Certificate Policy

and Certification Practices Framework [16] IETF RFC 5280 (2008) – Internet X.509 Public Key Infrastructure; Certificate

and Certificate Revocation List (CRL) Profile [17] IETF RFC 6960 X.509 Internet Public Key Infrastructure Online Certificate

Status Protocol – OCSP (2013) [18] HRN ISO/IEC 9594-8:2015 - Informacijska tehnologija – Međusobno

povezivanje otvorenih sustava – Imenik – 8. dio: Okviri certifikata javnog ključa i atributnog certifikata (ISO/IEC 9594-8:2014); Information technology – Open Systems Interconnection – The Directory – Part 8: Public-key and attribute certificate frameworks (ISO/IEC 9594-8:2014)

[19] CA/Browser Forum - Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (current version)

[20] IETF RFC 6844 – DNS Certification Authority Authorization (CAA) Resource Record (2013)

Fina's Documents [21] Certificate Policy and Certification Practice Statement for Fina Root CA,

CP/CPSROOT [22] Certificate Policy for Certificates for Website Authentication, CPWSA-eIDAS [23] Certification Practice Statement for Non-qualified Certificates, CPSNQC-eIDAS



1 INTRODUCTION

As a Trusted Third Party, Fina has been providing certification services since 2003. The trust services Fina provides are in accordance with legal regulations [1], [2] and [3] and thereby also with the applicable international standards within the scope of trust services provision. Fina continuously keeps track of Subscribers' needs, technology development and modifications to standards within the scope of trust services provision, and improve and adjust its PKI system accordingly so as to adjust its products and services to the cross-border interoperability demands.

1.1 Overview

Fina PKI is the PKI infrastructure established at Fina by which Fina provides trust services which refer to issuance and management of production certificate life-cycle (hereinafter referred to as: "certification services") and electronic Time-Stamp issuing.

Hierarchical structure of Fina PKI rests on Fina Root CA and is based on two-tier architecture of production Certification Authorities (hereinafter referred to as: "CA" or "CAs")

Fina's two-tier architecture of production Certificate Authorities includes:

• Root Certification Authority (root CA): Fina Root CA • Two subordinate Certification Authorities:

o Fina RDC 2015, o Fina RDC-TDU 2015.

Fina Root CA issued a self-signed Fina Root CA certificate as well as certificates to its subordinate Fina RDC 2015 and Fina RDC-TDU 2015 CAs.

Fina RDC 2015 and Fina RDC-TDU 2015 are CAs which issue certificates for end-Subscribers (hereinafter referred to as: "Subscriber's certificates").

The certificate policy and practice which refers to Fina Root CA and Fina PKI hierarchy based on Fina Root CA are described in the document Certificate Policy and Certification Practice Statement for Fina Root CA, CP/CPSROOT [21].

1.1.1 Scope and purpose

This Certification Practice Statement for Website Authentication Certificates (herein referred to as: CPSWSA-eIDAS) contains the description of processes and procedures applied by Fina PKI which refer to issuance and management of (non-qualified) digital production website authentication certificates' life-cycle (known as TLS/SSL certificates), which comply with the requirements of Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC [1] (hereinafter referred to as: "Regulation (EU) No 910/2014"). These website authentication certificates include validated data on the identity of the Subscriber organisation (hereinafter referred to as: "OVCP



certificate" or "certificate") pursuant to the requirements of the Certificate Policy for Website Authentication Certificates (hereinafter referred to as: "Certificate Policy") [22].

The scope of this CPSWSA-eIDAS comprises the trust services provided by Fina, which refer to issuance and management of the life-cycle of production certificates for website authentication, the private key of which is protected by a software token, or which is issued for use in HSM modules.

Production certificates from the scope of this CPSWSA-eIDAS constitute the Register of digital certificates (Fina RDC). Certification Authority (CA) from the scope of this CPSWSA-eIDAS is Fina RDC 2015 CA.

This CPSWSA-eIDAS is in compliance with the Certificate Policy [22], published on the web page http://www.fina.hr/finadigicert.

The purpose of this document is to define procedures from the scope of this document, implemented by all Fina PKI participants mentioned in Section 1.3 hereof.

The structure of this document is based on the standardization document IETF RFC 3647 [15].

1.1.2 Certificate Types

Fina as a Trust Service Provider issues Certificates for website authentication that fall within the scope of this document and shown in the Table 1.1. The Table contains the certificate type names and Certificate Policy OIDs (hereinafter referred to as: "CP OID") assigned by Fina, ETSI and CAB Forum.

Fina RDC 2015 website authentication certificates Certificate group

name Certificate type name CP OID Security level

Fina RDC 2015 certificates for website authentication

SSL Certificate Level 2 (OVCP) Fina CP OID: 1.3.124.1104.5.12.14.2 ETSI CP OID: 0.4.0.2042.1.7 CAB Forum CP OID: 2.23.140.1.2.2

Medium

SSL Certificate Level 3 (OVCP) Fina CP OID: 1.3.124.1104.5.12.14.3 ETSI CP OID: 0.4.0.2042.1.7 CAB Forum CP OID: 2.23.140.1.2.2

High

Table 1.1 Types of certificates for website authentication

Fina RDC 2015 website authentication certificates are issued for servers associated to the Legal persons with registered office location in the Republic of Croatia. Fina RDC 2015 CA issues the following certificate types of website authentication certificates:

• SSL Certificate Level 2 (OVCP) – Certificate for website authentication of medium level security, the private key of which is stored in a software protected token pursuant to Section 6.2.1 hereof. This certificate type complies with the "OVCP" certificate policy from the ETSI EN 319 411-1 [7] standard.

http://www.fina.hr/finadigicert



• SSL Certificate Level 3 (OVCP) – Certificate for website authentication of high level

security, the private key of which is stored in an HSM module pursuant to Section 6.2.1 hereof. This certificate type complies with the "OVCP" certificate policy from the ETSI EN 319 411-1 [7] standard.

1.2 Document name and identification

British Standards Institution (BSI) International Code Designator (ICD) assigned the OID to Fina. Based on that OID, Fina has for the needs of Fina PKI assigned the OID: 1.3.124.1104.5.

Listed below are the Document Name and the corresponding identification data.

• Name: Certification Practice Statement for Certificates for Website Authentication • Version: 1.2 • Effective date: 01 August 2018 • OID: 1.3.124.1104.5.0.5.2.1.2 • The following web page contains this CPSWSA-eIDAS :

- http://rdc.fina.hr/RDC2015/FinaRDC2015-CPSWSA1-2-en.pdf

1.3 PKI participants

Participants within Fina PKI are:

• Certification Authorities (CAs), • Registration Network (RA Network) consisting of Registration Authorities (RAs) and

Local Registration Authorities (LRAs), • Subscribers, • Relying Parties.

1.3.1 Certification authorities

The Certification Authority within Fina PKI within the scope of this CPSWSA-eIDAS is Fina RDC 2015.

In the issued certificate, Fina RDC 2015 CA is identified as the Issuer and signs it using its private key.

Fina RDC 2015 CA issues certificates to the public referred to in Table 1.1. in Section of 1.1.2 hereof. Pursuant to the same Certificate Policy, Fina RDC 2015 CA issues certificates to Fina.

Basic data on Fina RDC 2015 CA certificate are provided in Table 1.2.

Field Attribute Value

http://rdc.fina.hr/RDC2015/FinaRDC2015-CPSWSA1-2-en.pdf



Issuer

commonName Fina Root CA

organizationName Financial Agency

countryName HR

Validity notBefore 25 November 2015 11:13:30

notAfter 25 November 2025 11:43:30

Subject

commonName Fina RDC 2015

organizationName Financial Agency

countryName HR

Thumbprint SHA1: d8:86:43:90:c7:6c:9b:71:f0:40:4f:f3:76:fc:38:fd:73:78:7d:08

Table 1.2. Basic data on Fina RDC 2015 CA certificate

Fina RDC 2015 CA certificate is available on the following Internet address: http://rdc.fina.hr/RDC2015/FinaRDCCA2015.cer.

1.3.2 Registration authorities

Subscriber registration for Fina RDC 2015 CA is performed by Fina Registration Authorities.

Fina RA Network is comprised of Local Registration Authority networks (hereinafter referred to as: "Fina LRA") in Fina's business network and the Central Fina RA. Central Fina RA consists of the RDC Department authorised personnel. Subscriber registration with Fina RA Network is carried out by Fina LRA together with the Central Fina RA. Registration tasks in Fina RA Network are coordinated by the Central Fina RA, which is the central communication point of Fina RA Network. The list of existing registration offices of Fina LRA may be found at http://www.fina.hr/finadigicert.

Registration in Fina RA Network is conducted by authorized persons who have been assigned the trusted role of the Registration Officer.

Obligations and responsibilities of Fina RA Network and the External RAs are listed under Section 9.6.2 hereof.

1.3.3 Subscribers

A Subscriber within the scope of this CPSWSA-eIDAS is a Legal person with registered office location in the Republic of Croatia who undertook contractual obligations of a Subscriber by concluding an agreement with Fina as the Trust Service Provider.

In order to use a certification service, Subscribers complete the process of submitting their applications and registering, as well as accept Subscriber obligations and responsibilities referred to in Section 9.6.3 hereof. Subscribers conclude a Subscriber Agreement with Fina.

http://rdc.fina.hr/RDC2015/FinaRDCCA2015.cer




1.3.3.1 Certification Subjects

Certification Subject in certificates is a server that is identified as a Subject in the certificate, and is the holder of the private key connected to the public key in the certificate.

1.3.4 Relying parties

Relying Parties are Natural persons - citizens or Legal persons who rely on the trust service. The certificate enables the Relying Party to check a subject identity.

Obligations and responsibilities of the Relying Party are listed in Section 9.6.4 hereof.

1.3.5 Other participants

No stipulations.

1.4 Certificate usage

Based on certificate type purpose, permitted use and use restrictions, the Relying Party decides whether a certain certificate is adequate and reliable for use and acceptance. The Relying Party is responsible for accepting and acting in reasonable reliance on the certificate which has a certain security level. When deciding on the acceptance of a certificate, the Relying Party should consider the following:

• all certificate data or the facts of which the Relying Party is aware, including this CPSWSA-eIDAS,

• transaction or information economic value, if applicable, • potential losses or damages that may be incurred by incorrect identification of the

Certification Subject by the Relying Party, • legislation applicability, • any adequacy or inadequacy indicator or other fact the Relying Party is aware of and

which refers to the Certification Subject, the applied solution or transaction, • recommended financial limit regarding the certificate's security level.

Security levels of certificates are described in Table 1.3. The table shows the pertaining scope of application and recommended financial limit for individual security levels.

Security level Scope of Application Recommended financial limit

Medium This level is adequate for transactions of medium value and in environments in which the potential certificate misuse may cause medium damage or where the certificate misuse risk is medium.

up to HRK 80,000.00

High This level is adequate for transactions of high value and in environments in which the potential certificate misuse may cause great damage or where the certificate misuse risk is large.

up to HRK 400,000.00

Table 1.3. Security levels of certificates



1.4.1 Appropriate certificate uses

Certificates listed in Table 1.1 hereof and the pertaining private keys are used only for website authentication, i.e. authentication of web servers accesses through TLS or SSL protocol.

1.4.2 Prohibited certificate uses

Apart from the use referred to in section 1.4.1 hereof, all other uses of certificates listed in Table 1.1. and their private keys is forbidden.

1.5 Policy administration

1.5.1 Organization administering the document

Fina remains authorized and responsible for creation and update of the Certificate Policy and this CPSWSA-eIDAS document.

Authorized persons in Fina’s organizational units participating in the development, maintenance, implementation and approval of policies and practices that are applied in provision of trust services in Fine PKI hereinafter are called collectively the Fina PMA.

Amendments and updates of the Certificate Policy and this CPSWSA-eIDAS document are performed and based on internal proposals and requirements for harmonization with the legislation and the relevant standards.

1.5.2 Contact person

Contact details for administration and content of this CPSWSA-eIDAS are given below.

Mailing address:

Fina Sektor komercijalnih digitalnih rješenja Ured za upravljanje politikama e-poslovanja Koturaška cesta 43 10000 Zagreb Croatia

Telephone: +385-1-6128-171 Fax: +385-1-6304-081 E-mail: [email protected]

1.5.3 Person determining CPS suitability for the policy

Fina PMA establishes the compliance of this CPSWSA-eIDAS with the Certificate Policy.




Fina PMA is responsible for the compliance of this CPSWSA-eIDAS with the Certificate Policy [22].

1.5.4 CPS approval procedures

Design, approval and entry into force of this CPSWSA-eIDAS that confirm its compliance with the Certificate Policy is described in the Section 9.12.1 hereof.

1.6 Definitions and acronyms

1.6.1 Definitions

TERM MEANING

Activation Data Confidential data necessary to access or activate the cryptographic module. Activation data may be a PIN, password or electronic key which the person knows or possesses.

Advanced Electronic Signature Electronic signature that meets the following requirements:

(a) it is uniquely linked to the Signatory;

(b) it is capable of identifying the Signatory;

(c) it is created using electronic signature creation data that the Signatory can, with a high level of confidence, use under its exclusive control; and

(d) it is linked to the signed data in such a way that any subsequent change in the data is detectable.

Application Software Provider A provider of an internet browser or other application software displaying or using certificates and integrating root certificates.

Authentication An electronic process that enables the electronic identification of a natural or Legal person, or the origin and integrity of data in electronic form to be confirmed.



TERM MEANING

Business Entity 1. Legal persons, such as companies, credit and financial institutions, public and private institutions, associations with Legal personality, non-profit and non-government organizations with Legal

personality, funds with Legal personality, local and regional self-government units (municipalities,

towns and counties) etc. 2. Public authorities, such as state authorities, state administration bodies, state agencies etc.

3. Natural persons - citizens with a registered business, such as trades people, attorneys, notaries public etc.

CA Certificate Public-key certificate for one CA issued by another CA or by the same CA.

Central RA Central registration office that is primarily in charge of coordinating the entire RA Network, but may also directly perform Subscriber registration.

Certificate See the term "Public Key Certificate".

Certificate for electronic signature

Electronic attestation that connects the electronic signature validation data with the natural person and confirms at least the name or pseudonym of that person.

Certificate for website authentication

An attestation that makes it possible to authenticate a website and links the website to the natural or Legal person to whom the certificate is issued.

Certificate Policy (CP) A named set of rules which indicates the certificate applicability on a certain group and/or class of applications with common security requirements.

Certificate Revocation An action that makes a certificate irrevocably invalid from the moment of revocation.

Certificate Revocation List (CRL)

Signed list indicating a set of certificates that are no longer considered valid by the certificate issuer.

Certificate Validation Process of verifying and confirming that a certificate is valid.



TERM MEANING

Certification Authority (CA) Authority trusted by one or more users to create and assign public-key certificates.

A Certification Authority may be: 1. A trust service provider creating and assigning public-key

certificates; or 2. A technical certificate-issuing service used by the certification

service provider creating and assigning public-key certificates.

Certification Practice Statement (CPS)

Statement of the practices which a Certification Authority employs in issuing managing, revoking, and renewing or re-keying certificates.

Certification Services Services of issuance and lifecycle management of certificates.

Certification System System of IT products and components organised for providing certification services.

Conformity Assessment Body A body defined in point 13 of Article 2 of Regulation (EC) No 765/2008, which is accredited in accordance with that Regulation as competent to carry out conformity assessment of a qualified trust service provider and the qualified trust services it provides.

Coordinated Universal Time (UTC)

Second-based time scale as defined by ITU-R Recommendation TF.460-5. For most practical applications, UTC is equivalent to mean solar time of the Prime Meridian (0°). More precisely, UTC is a compromise between the very stable atomic time (fr. Temps Atomique International - TAI) and solar time derived from irregular Earth's rotation (in relation to the agreed Greenwich mean sidereal time (GMST).

Cryptographic Module Software or device of a certain security level which: generates a key pair, and/or protects cryptographic information, and/or performs cryptographic functions.

Custodian A natural person employed at the Legal person or associated in another way with the Legal person, and who has been authorised by the same Legal person to submit applications for the issuance of business certificates for systems and devices, for the renewal, revocation, suspension and reactivation of certificates, and to accept certificates and corresponding activation data.

The Custodian is authorised to submit requests for lifecycle management of certificates

The Custodian is the contact person for managing the life cycle of the Subject certificate.

Distinguished Name (DN) A unique name of the Subject entered in the certificate. The distinguished name uniquely identifies the Subject to whom the certificate is issued and it is unique within one CA.



TERM MEANING

Domain Contact The Domain Name Registrant, technical contact, or administrative contract (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar.

Domain Name Registrant Sometimes referred to as the “owner” of a Domain Name, but more properly the person(s) or entity(ies) registered with a Domain Name Registrar as having the right to control how a Domain Name is used, such as the natural person or Legal Entity that is listed as the “Registrant” by WHOIS or the Domain Name Registrar.

Electronic Signature Data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign.

Electronic Signature Creation Data

Unique data which is used by the signatory to create an electronic signature.

Electronic Time Stamp Data in electronic form which binds other data in electronic form to a particular time establishing evidence that the latter data existed at that time.

Fina LRA Local Registration Authority in Fina business network.

Fina PKI

Public Key Infrastructure (PKI) established in Fina which is intended for providing certification services to natural persons (citizens), business entities and state administration authorities, and which operates as the Trusted Third Party.

Fina RA Network Fina Registration Authority Network consists of the Central Fina RA and Fina LRA.

Internal Name A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA’s Root Zone Database.

Key Pair Two uniquely linked cryptographic keys, one of which is a private key and another is a public key.

Legal Representative A person legally authorised to represent the Subscriber which is a Legal Person.

OVCP certificates A certificate which includes verified information on the identity of the organisation related to the subject.

Policy Management Authority (PMA)

Body with final authority and responsibility for specifying and approving the Certificate Policy.



TERM MEANING

Private Key In a public key cryptographic system, that key of an entity's key pair which is known only by that entity.

Public Directory IT system which is used for online publication of information concerning certificates, including information on certificate revocation.

Public Key In the cryptographic public key system, a publicly known key from the Subject’s key pair.

Public Key Certificate Public key of an entity, together with some other information, rendered unforgeable by digital signature with the private key of the certification authority which issued it.

Public Key Infrastructure (PKI) Infrastructure able to support the management of public keys able to support authentication, encryption, integrity or non-repudiation services.

Qualified Auditor Natural or Legal person that meets the requirements stated in the document Baseline Requirements [19], published by the CA/Browser Forum.

Qualified Trust Service Provider

A trust service provider who provides one or more qualified trust services and is granted the qualified status by the supervisory body.

Random Value A value specified by a Trust Service Provider to the Applicant that exhibits at least 112 bits of entropy.

RA Network The complete registration authority network consisting of the Fina RA Network and of external RAs with which Fina concluded an agreement on the registration services.

Registration Authority (RA) Authority responsible for identification and authentication of certification subjects, as well as other persons or organisations.

Registration Officer Person responsible for data confirmation necessary for certificate issuance and authorisation of application for certificate issuance.

Regular Certificate Renewal Certificate renewal in Fina PKI means issuance of a new certificate the parameters of which are the same as the parameters of the certificate to which the application relates, but with a new public key, new certificate serial number, new operational period and new signature of the same CA, and is carried out in the defined period before the expiry of certificate validity.

Relying Party Natural or Legal person that relies upon an electronic identification or a trust service.

Reserved IP address IPv4 or IPv6 address which IANA marked as reserved.



TERM MEANING

Revocation Officer Person responsible for the change of the certificate's operative status.

Root CA Certification authority which is at the highest level within trust service providers domain and which is used to sign subordinate CA(s)

Root CA certificate CA Certificate that the Root CA issued to itself.

Secure Cryptographic Device Device which holds the Subscriber's private key, protects this key against compromise and performs signing or decryption functions on behalf of the user.

Signatory A natural person who creates an electronic signature.

Signature verification Process of checking the cryptographic value of a signature using signature verification data.

Signature Verification Data Data, such as codes and public cryptographic keys used for the purpose of signature verification.

State Administration Body (TDU)

State authority body responsible for performing state administration tasks in the administrative domain of its competence. State administration bodies include ministries, state offices, administrative organizations and county state administration offices or other state administration bodies established by the applicable law in force.

Subject Entity identified in a certificate as the holder of the private key associated to the public key given in the certificate.

Subscriber Legal or natural person bound by agreement with a trust service provider to any Subscriber obligations.

Trust Service Provider A natural or a Legal person who provides one or more trust services either as a qualified or as a non-qualified trust service provider.

Trusted list List that provides information about the status and the status history of the trust services from trust service providers regarding compliance with the applicable requirements and the relevant provisions of the applicable legislation.

Trusted Roles Roles which are responsible for safe operation of the trust service provider. Trusted Roles and the corresponding responsibilities are clearly described by the Trust Service Provider in the employee's job description.

Validation Process of verifying and confirming that an electronic signature or a seal is valid.

Validation data Data used for electronic signature or electronic seal validation.



TERM MEANING

Validation Specialist Person responsible for data verification related to certificate issuance according to CA/Browser Forum BRG [19] document.

Table 1.4. Definitions

1.6.2 Abbreviations

ABBREVIATION FULL NAME

CA Certification Authority

CAA Certification Authority Authorization

CAB Forum CA/Browser Forum

ccTLD Country Code Top-Level Domain

CP Certificate Policy

CPWSA-eIDAS Certificate Policy for Certificates for Website Authentication

CPS Certification Practice Statement

CPSNQC-eIDAS Certification Practice Statement for Non-Qualified Certificates

CPSWSA-eIDAS Certification Practice Statement for certificates for website authentication

CRL Certificate Revocation List

FQDN Fully Qualified Domain Name

DN Distinguished Name

DNS Domain Name System

LCP Lightweight Certificate Policy

LDAP Lightweight Directory Access Protocol

LRA Local Registration Authority

OCSP Online Certificate Status Protocol

OVCP Organizational Validation Certificate Policy

OID Object Identifier

PIN Personal Identification Number

PKI Public Key Infrastructure

PMA Policy Management Authority

RA Registration Authority

SOA Start of Authority



ABBREVIATION FULL NAME

TDU State Administration Body (Bodies)

TLD Top-Level Domain

UTC Coordinated Universal Time Table 1.5. Abbreviations



2 PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1 Repositories

The Fina PKI repository is managed by Fina as a Certification Service Provider. Fina is responsible for the operation of Fina PKI repositories and for the publication of documents and information on the repositories.

Fina ensures the accessibility of repositories on websites with availability of 24 hours a day, 7 days a week.

2.2 Publication of certification information

Documents and information on certification services provision are available to the public and published on the Fina PKI repository.

The repository consists of a part available on web pages and a part available via public LDAP directory.

2.2.1 Repository Contents

The following is published on Fina PKI repository web pages:

• current Certificate Policy, • this Certification Practice Statement, • prior versions of the Certificate Policy and the Certification Practice Statement, • Terms and Conditions and PKI disclosure statement, • valid certificate profiles description, • certification services price list, • certificate application forms, • subscriber agreement forms, • application forms for revocation of the certificate, • authorisation forms, • Fina Root CA certificate and Fina RDC 2015 CA certificate, • consolidated CRL Fina RDC 2015 CA, • information on legislation in the field of certification services provision, • information on the existence of business-relevant document that cannot be

completely or at all published due to sensitivity or confidentiality of content, • Fina LRA current location, • subscriber instructions, • certificates for checking and testing, • notifications to Subscribers and Relying Parties related to certification service

provision, • other information related to Fina RDC 2015 CA operation.



It is possible to search through the public directory and retrieve certificates issued by a Fina RDC 2015 CA via the repository web page. In order to find the required certificate, it is necessary to know and enter the basic data about the subject.

The content published on the web pages may be accessed via http://www.fina.hr/finadigicert in Croatian and English.

In public directory the following is published:

• Fina RDC 2015 CA certificate, • consolidated CRL and segmented CRL for each Fina RDC 2015 CA.

The address of the LDAP directory for Fina RDC 2015 is ldap://rdc-ldap2.fina.hr.

Information on the status of certificates issued by Fina RDC 2015 CA is available via Fina OCSP service. The address of Fina OCSP service is http://ocsp.fina.hr.

Addresses where CRL Fina RDC 2015 CA is published are listed in Section 4.10.1 hereof.

Confidential data are not disclosed in the Fina PKI repository.

Fina hosts test Web pages that allow Application Software Providers to test their software with Subscriber Certificates that chain up to publicly trusted Fina Root CA Certificate. For that purpose Fina hosts separate Web pages using Subscriber Certificates that are valid, expired and revoked on following Web addresses:

• https://testsslvalid.fina.hr, • https://testsslexpired.fina.hr, • https://testsslrevoked.fina.hr.

2.2.2 Contents Publication and Repository Management Procedures

Upon authorisation, documents publication on repository is performed by the authorised person in charge of contents management of the online part of the repository.

Issued certificates and their pertaining information are published upon their publication.

Fina PMA authorises the publication of documents containing certification services terms and conditions, as well as application, contract and authorisation forms. These documents are published without prior announcement, and older versions of the documents are deleted from the repository.

Fina RDC 2015 CA automatically publishes pertaining CRLs in the public directory and the website of the repository following their publication.

Publication of the new version of price list is approved by the head of the e-Business Centre.


ldap://rdc-ldap2.fina.hr/

http://ocsp.fina.hr/

https://testsslvalid.fina.hr/

https://testsslexpired.fina.hr/

https://testsslrevoked.fina.hr/



Notifications and information may be made available to subscribers on the website of the repository without the authorisation of Fina PMA, but Fina PMA must be informed about every notification and information publication in a timely manner.

2.3 Time or frequency of publication

Fina annually maintains, updates, approves, publishes and applies the Certificate Policy and this CPSWSA-eIDAS. Prior versions of these documents remain published on the repository at least until the expiry of the certificates issued pursuant to the respective documents.

Other Fina PKI documents and other relevant information referred to in Section 2.2.1 hereof are published as required, after the authorisation by the Fina PMA.

Subscriber certificates are made available for retrieval from the repository immediately upon their issuance.

The frequency of publishing CRLs for certificates issued by Fina RDC 2015 CA is defined in the Section 4.9.7 hereof.

Online information on issued certificates status is available via Fina OCSP service described in Section 4.9.9 hereof.

2.4 Access controls on repositories

Documents and information published in the Fina PKI repository is free and publicly available to all Fina PKI participants.

Fina established access control over the repository with the aim of preventing unauthorised adding, modifying or deleting information and protecting its integrity and authenticity. Mode of access to documents and information published on the repository is read-only.

Fina's authorised personnel have the authorisation to add, modify or delete information in the Fina PKI repository.



3 IDENTIFICATION AND AUTHENTICATION

Subject identification and identity authentication for Fina PKI is conducted by the Fina RA network. Fina RA network consists of the Central Fina RA and Fina LRA. Employees authorised for registering with the Fina RA network conduct registration tasks pursuant to this CPSWSA-eIDAS.

3.1 Naming

3.1.1 Types of names

Subject information entered into the certificate refers to the Subject’s authentic name. The "Subject" field is in line with the IETF RFC 5280 [16] recommendation.

The "Subject" field in OVCP certificates contains the fully qualified domain name (hereinafter referred to as: "FQDN") or server IP address.

If any data entered into the attributes localityName and organizationName of the "Subject" field contains special characters or characters that do not form part of the English or Croatian alphabet, those characters are replaced by the most proximate character of the English alphabet pursuant to Fina's rules on the use of wild cards.

3.1.2 Need for names to be meaningful

The value of the "Subject" field attribute is determined in the following manner:

• serialNumber: Indicator of Legal person, that includes meaningful content: "VAT”, 2-letter ISO code for Legal person’s country of residence, “-", Legal Person’s OIB,”.”, W (internal Fina’s designation)

• commonName: FQDN or server IP address, • localityName: Legal person registered office location, • organizationName: Name of the Legal person, • countryName: HR.

Extension Subject Alternative Name contains the FQDN or server IP address.

3.1.3 Anonymity or pseudonymity of subscribers

Anonymity or pseudonymity of subscribers is not supported.

3.1.4 Rules for interpreting various name forms

The interpretation of the name form in the Subject field according to X.520 [x] standard is carried out in the following way:



Interpretation of certificates' name form

Attribute pursuant to X.520 Fina RDC 2015 Explanation

serialNumber VAT, 2-letter ISO country code of the Legal person's country of residence, "-", Legal Person’s OIB,”.”, W (Fina’s internal number)

E.g. VATHR-12345678901.1

commonName (CN) Fully qualified domain name (FQDN) or server IP address

Only one fully qualified domain name (FQDN) or only one server IP address

localityName (L) Legal person registered office location

Legal person registered office location

organizationName (O) Full registered abbreviated name of the Legal person

Full registered abbreviated name of the Legal person or name of Legal person if the abbreviated name has not been registered

countryName (C) HR 2-letter ISO country code of the Republic of Croatia

Table 3.1. Interpretation of certificates' name form according to X.520 standard

The Subject Alternative Name extension contains at least one FQDN or one server IP address, one of which is the FQDN or server IP address entered for the Common Name attribute.

Using a wildcard in the FQDN name or IP address is not allowed.

The Subject Alternative Name extension does not contain the reserved IP address or internal name.

3.1.5 Uniqueness of names

The distinguished name of the Subject is unique within the Fina PKI production hierarchy based on Fina Root CA.

The uniqueness of the name in these OVCP certificates is ensured through the value of the attribute Serial Number and Common Name in the Subject field of the certificate by means of entering this FQDN or server IP address into the distinguished name attribute of the certificate.

3.1.6 Recognition, authentication, and role of trademarks

In case the Subscriber applies for issuance of a certificate containing a trademark, Fina RA network checks that the trademark is used legitimately, and in case of a founded complaint, Fina has the right to revoke such a certificate.



In case the Subscriber applies for issuance of a certificate containing a trademark, Fina RA may ask for evidence of registering the trademark with the competent authority.

3.2 Initial identity validation

Fina carries out the verification of data collected in the Subscriber registration procedure by comparing it to the data from the delivered documentation and, if applicable, through communication channels in accordance with the legislation in force.

When issuing certificates from the scope of this CPSWSA-eIDAS, Fina verifies and confirms the Custodian's identity based on immediate physical identification or by using methods providing an appropriate security level when establishing identity.

3.2.1 Method to prove possession of private key

3.2.1.1 Proving the possession of a private key for SSL Certificate Level 2 (OVCP)

Fina may generate the key pair for SSL Certificate Level 2 (OVCP) at its location, and the Custodian may generate it at the location of the Subscriber, as described in Section 6.1.1.2 hereof.

a) Fina generates the key pair

If the key pair generation for SSL Certificate Level 2 (OVCP) is performed by Fina, the proof that the Custodian is in possession of a private key whose public key has been delivered for certification is ensured in the following manner:

• Registered and authenticated Custodian generates the key pairs through the use of Fina CMS, pursuant to the procedure described in the Section 4.3.1.1. a) hereof.

• Key pair generation at Fina is carried out in accordance with Section 6.1.1.2 hereof, • Issuance of SSL Certificate Level 2 (OVCP) is performed pursuant to

Section 4.3.1.1.a) hereof, • The Custodian, through the use of Fina CMS and the secure TLS channel, retrieves

the issued key pair and certificate in a PKCS#12 file protected by activation data and in that way come into possession of the private key.

b) Custodian generates the key pair at the location of the Subscriber

If the key pair generation for SSL Certificate Level 2 (OVCP) is performed by the Custodian at the location of the Subscriber, the proof that the Custodian is in possession of a private key whose public key has been delivered for certification is ensured in the following manner:

• The Custodian generates a key pair for SSL Certificate Level 2 (OVCP) pursuant to Section 6.1.1.2 hereof at the location of the Subscriber.

• The Custodian makes a PKCS#10 request at the location of the Subscriber that contains the public key from the generated key pair, and he/she signs the application with his/her private key from the same generated key pair.



• Registered and authenticated Custodian sends a PKCS#10 certificate request to Fina

RDC 2015 CA through the use of Fina CMS and the secure TLS channel. • Before issuing the certificate, Fina RDC 2015 CA determines that the Custodian is in

possession of a pertaining private key through verification of the signature in the PKCS#10 request.

3.2.1.2 Proving the Possession of a Private Key for SSL Certificate Level 3 (OVCP)

Key pair for the SSL Certificate Level 3 (OVCP) is always generated by the Custodian within the HSM module at the location of the Subscriber, as described in Section 6.1.1.2 hereof. The proof that the Custodian is in possession of the private key whose public key has been delivered for certification is ensured in the following manner:

• The Custodian always generates the key pair within the HSM at the location of the Subscriber, pursuant to the HSM certification documentation,

• Public key is forwarded for certification to a certain Fina RDC 2015 CA on the basis of a PKCS#10 request signed by the pertaining private key pair and through the use of a safe TLS channel. The Custodian is responsible for ensuring that the public key delivered for certification originates from the key pair generated within the HSM.

• Before issuing the certificate, Fina RDC 2015 CA determines that the Custodian is in possession of a pertaining private key through verification of the signature in the PKCS#10 request.

3.2.2 Authentication of organization and domain identity

3.2.2.1 Authentication of organization identity

Certificate applicant provides accurate and completely filled Legal person data in the certificate application, which are signed by the Legal Representative.

Furthermore, Legal persons, depending on applicable laws and regulations of the Republic of Croatia which regulate Legal persons' activities, enclose the following documentation to establish the Legal personality and identity:

• Original or copy of a valid excerpt, accompanying the original, not older than six months, from the competent register, pursuant to laws and regulations of the Republic of Croatia, as proof of registration with the competent business activity registry or law, or other law pursuant to which the Legal person was established, provided that it is not required that the Legal person be registered with the competent registry,

• Copy of the identification document of the Legal Representative.

Upon the initial collection of data contained in the application and reception of the enclosed documentation, Legal person's identification and authentication is done in the following manner:



• The integrity, authenticity and validity of Legal person registration documentation is

verified. • It is verified whether the Legal person has been registered with the competent

registry if it is required to do so according to regulations or pursuant to the act of the competent body or the Legal person founding act, provided that the Legal person is not required to register with the registry.

Fina RA network additionally verifies the accuracy of confidential data entered in the application. The verification is conducted based on the enquiries to the national OIB system via the Fina RA application for data obtainable from the OIB system.

The authorisation of the Legal person's Legal Representative and the accuracy of its personal data are verified. If the Legal Representative authorises the proxy, the authorisation form is verified based on the signature from the copy of the identification document of Legal Representative, and the proxy data are verified based on the delivered identification document copy with prior verification of the authorisation of the Legal person's Legal Representative.

In case of modification of Legal person's data contained in the certificate, the Subscriber is required to deliver proof of data modification within seven days, and the Registration Officer, after their verification, enters the modified Legal person's data into the certificate.

In case of already registered Legal person for which the new certificate application or contract is to be signed by the Legal Representative which has not been registered with the RA network, it is deemed necessary to submit a new, valid excerpt from the competent registry during the certificate application that confirms the powers of the Legal Representative, together with the copy of the identification card of that Legal Representative. Verification procedure is then identical to the initial verification procedure of the Legal person's identity. If an already registered Legal Representative is no longer stated in the new resolution of the competent registry, the Registration Officer erases it from the list of registered Legal Representatives of that Legal person in the Fina RA application.

In case of modification of Legal person data that are not contained in the certificate, the Certificate Applicant is required to submit proof of data modification during next certificate application or renewal request, and the Registration Officer, after their verification, enters the modified Legal person data into the certificate.

3.2.2.2 Verification of Country Related to the Subject

Central Fina RA verifies whether the country that has been entered into the countryName field of the certificate is related to the Subject entered in the field commonName of the certificate before approving the certificate application.

This verification is performed by Validation Specialist in one of the following ways:

• It is verified whether the address area of the Subject's IP address had been assigned by the country entered into the countryName field of the certificate. The relation of the



IP address and FQDN submitted in the certificate application is verified through comparison with the pertaining DNS record kept by the competent body.

• Information provided by the person registering the name of the domain is verified.

3.2.2.3 Validation of Domain Authorization or Control

Before approving the certificate issuance, Validation Specialist in Central Fina RA for every FQDN listed in certificate application verifies the authenticity and accuracy of the domain name and also verifies the property or right to use the domain name by the Legal person submitting the certificate application.

3.2.2.3.1 E-mail, telefax, or Postal Mail to Domain Contact

The validation method is based on Chapter 3.2.2.4.2 of the CA/Browser Forum BRG [19] document.

This validation method is done by sending a Random Value via e-mail, telefax, or postal mail and then receiving a confirming response utilizing the Random Value. The Random Value is sent to an e-mail address, telefax number, or postal mail address identified as a Domain Contact.

Each e-mail, telefax, or postal mail may confirm control of multiple Authorization Domain Names.

The central Fina RA may send the e-mail, telefax, or postal mail identified under this section to more than one recipient provided that every recipient is identified by the Domain Name Registrar as representing the Domain Name Registrant for every FQDN being verified using the e-mail, telefax, or postal mail.

The Random Value is unique in each e-mail, telefax, or postal mail.

The central Fina RA may resend the e-mail, telefax, or postal mail in its entirety, including re-use of the Random Value, provided that the communication's entire contents and recipient(s) remain unchanged.

The Random Value remains valid for use in a confirming response for no more than 30 days from its creation.

3.2.2.3.2 Constructed e-mail to Domain Contact

The validation method is based on Chapter 3.2.2.4.4 of the CA/Browser Forum BRG [19] document.

This validation method is done by:

• sending an e-mail to one or more addresses created by using “admin”, “administrator”, “webmaster”, “hostmaster”, or “postmaster” as the local part, followed by the atsign ("@"), followed by an Authorization Domain Name,

• including a Random Value in the e-mail, and



• receiving a confirming response utilizing the Random Value.

Each e-mail may confirm control of multiple FQDNs, provided the Authorization Domain Name used in the e-mail is an Authorization Domain Name for each FQDN being confirmed

The Random Value is unique in each e-mail.

The e-mail may be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient remains unchanged.

The Random Value remains valid for use in a confirming response for no more than 30 days from its creation.

3.2.2.4 Authentication for an IP Address

Before approving the certificate issuance, Validation Specialist in Central Fina RA for each IP Address listed in certificate application verifies the authenticity and accuracy of the IP Address and also verifies, as of the date the certificate was issued, the right to use and control the IP Address by the Legal person submitting the certificate application.

The validation is done by:

• Obtaining documentation of IP address assignment from the Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC),

• Performing a reverse-IP address lookup and then verifying control over the resulting Domain Name under Section 3.2.2.3 hereof, or

• Using any other method of confirmation, provided that the Fina as Trust Service Provider maintains documented evidence that the method of confirmation establishes that the Applicant has control over the IP Address to at least the same level of assurance as the methods previously described.

3.2.3 Authentication of individual identity

Initial identification and authentication of a Natural person - citizen acting as the Custodian is carried out by collecting and verifying personal data through direct or indirect identification procedures.

Initial identification and authentication of a Natural person - citizen for Fina PKI is conducted by the Fina RA network.

For the purpose of initial identification and authentication of the Natural person’s - citizen's identity, Fina collects and verifies the following personal data:

• Name and surname, • OIB (if it was assigned), • Date, place and country of birth, • Identification document data referred to in Section 3.2.3.3 hereof,



• Mailing address, • E-mail address, • Telephone Number.

For the purpose of issuing a certificate, Fina also collects evidence of the Custodian’s association with the Legal person the certificate is issued to.

Data contained in the application delivered by the Custodian must contain the name and surname, OIB, number of identification document with the date of its expiry, nationality and the telephone or mobile phone number. If the Custodian requests that the activation data be delivered via electronic mail or SMS, the application data must contain the e-mail address and mobile phone number.

Furthermore, for Croatian citizens, the data on the date and place of birth is gathered as well. These additional data are gathered through enquiries to the national OIB system and does not have to be entered into the application by the Custodian.

Identification of Natural persons - citizens that are foreign citizens may be conducted in two ways, depending whether the citizen has been assigned an OIB in the Republic of Croatia. In case that a foreign citizen has been assigned an OIB, identification is conducted in a manner equivalent to the identification of Croatian citizens. In case that the foreign citizen has not been assigned an OIB, the data on the date and place of birth, and place of residence is gathered. The Fina RA/LRA network gathers these additional data and verifies their accuracy through the comparison of the data contained in the enclosed documentation.

Registration Officer verifies all confidential data from the document enclosed by the Custodian and confirm the accuracy and integrity of information in the certificate application. Registration Officer validates the successful and correct identification of the Custodian, by signing the certificate issuance application and enters that data or delivers it in a protected form to Fina's Subscriber Registration System.

3.2.3.1 Direct identification procedure

Direct identification procedure for Natural persons - citizens is peformed in their physical presence, based on a valid identification document described in Section 3.2.3.3 hereof.

The direct identification and authentication procedure for Natural persons - citizens is implemented in the following manner:

• the integrity, authenticity and validity of the identification document is checked, • the accuracy of data on the Natural person - citizen and his/her signature from the

certificate application is verified through comparison of that data and signature with the data and signature from the identification document. Additionally, a verification of data from a valid identification document is performed through enquiries to the national OIB system, except for foreign citizens that have not been assigned an OIB in the Republic in Croatia.



3.2.3.2 Indirect identification procedure

The indirect identification procedure is performed in the manner assuring an appropriate security level of a Natural person’s – citizen’s identification.

a) Fina carries out the indirect identification procedure of Natural persons - citizens by means of a certificate of a qualified electronic signature which was issued based on direct identification of the Natural person - citizen.

b) Fina may also carry out the indirect identification procedure by verifying data from the copies of two different identification documents defined in Section 3.2.3.3. item b) hereof.

3.2.3.3 Eligible Types of Identification Documents

Natural persons - citizens prove their identity:

a) With a valid identity card or passport in the direct identification procedure, b) With a copy of two different identification documents containing a photograph, issued

by the competent national authority, in the direct identification procedure in accordance with Section 3.2.3.2. b) hereof. In this case, eligible identification documents are an ID card, passport or a driver’s licence.

Natural persons - citizens who do not possess an ID card or passport issued in the Republic of Croatia prove their identity with a valid identification document for entering the Republic of Croatia.

It is deemed necessary to contact the Fina PMA in order to obtain proof of identity through other types of identification documents with photographs issued by the competent national bodies.

3.2.4 Non-verified subscriber information

Certificates within the scope of this CPSWSA-eIDAS may only contain data which Fina verified or for which the applicant signed a statement on the accuracy of information in the certificate application and on assuming full liability in case of providing inaccurate or incomplete data.

3.2.5 Validation of authority

Before issuing a certificate, Fina conducts identity validation of the Legal Representative by verifying the data contained in the documentation provided for the purpose of Legal personality determination and identification under Section 3.2.2 hereof and by comparing the data from the copy of a valid identification document of the Legal Representative.

If multiple persons have been assigned autonomous and individual representation through the resolution on Legal person's registration with the competent registry or another act if the registration is not stipulated, the application and contract are signed by any person authorised for such representation.

If multiple persons have been assigned joint or group representation, the application and contract are signed by any person authorised for representation pursuant to the resolution or



another act if the registration is not stipulated or are signed by one person authorised for representation with the written consent of other persons who jointly represent the Legal person.

The Registration Officer establishes whether the person who has signed the application or the contract is the Legal representative based on the resolution on the registration with the competent registry or another act if the registration is not stipulated. When the application and contract are signed by a proxy of the Legal Representative, the RA network establishes whether the person who has signed the application or the contract is a proxy and whether the authorisation has been signed by the person authorised for representation.

The Registration Officer establishes the identity of the Legal Representative or the proxy of the Legal Representative that has signed the application or contract. Identity validation of the Legal representative or its proxy is conducted by verifying the data contained in the documentation provided for the purpose of the Legal person’s Legal personality determination and identification under Section 3.2.2 hereof and by comparing the data from the copy of a valid identification document of the person authorised for representation or its proxy. Eligible types of identification documents are listed in Section 3.2.3.3 hereof. Furthermore, an enquiry to the national OIB system is conducted, and all data contained in the OIB system are verified in relation to the data from the copy of the identification document.

Identification of the proxy of the Legal Representative is conducted in a manner equivalent to the Legal Representative identity validation.

3.2.6 Criteria for interoperation

No stipulations.

3.3 Identification and authentication for re-key requests

Fina carries out the procedures of identification and authentication of the applicant for the following purposes:

• Routine certificate renewal with new key pair generation (i.e. re-key), • Issuing certificates upon expiration, • Reissuing certificates upon revocation and • Certificate recovery.

If the pertaining terms and conditions of certification services provision from Section 9.16 hereof have been changed since the issuance of the certificate subject to renewal or reissuing, the current conditions of certification services provision are communicated to the Custodian who accepts them before the certificate is issued.



3.3.1 Identification and authentication for routine re-key

Routine renewal of the certificate is done near the end of the certificate life cycle and includes the procedure of certificate renewal for the Subject (see Sections 4.6. and 4.7 hereof).

Routine certificate renewal is carried out if all the terms and conditions referred to in section 4.7.1 hereof have been met.

Identification and authentication for routine certificate renewal is carried out at the location of the Fina RA network. Identification and authentication of the Custodian is carried out pursuant to the provisions referred to in Section 3.2.3 hereof.

Legal person verification is carried out through determining whether there had been changes in the Legal person's data in relation to data at the disposal of the Fina RA system. This verification is carried out through accessing the data from the submitted certificate application and enquiries to the national OIB system and, if applicable, through accessing the data published by the competent authority in a reliable manner. If the Legal person data contained in the certificate differ from the valid data of the Fina RA system, data modification procedure is conducted pursuant to Section 4.8 hereof.

If the application was signed by a person authorised for representation which had not been registered with the Fina RA application for that Legal person, the procedure referred to in Section 3.2.5 hereof is carried out.

3.3.2 Identification and authentication for re-key after revocation

Identification and authentication of the Applicant for certificate re-issuing after revocation is done in accordance with the initial identity validation procedure from Section 3.2 hereof.

3.3.3 Identification and authentication for re-key after expiry

Identification and authentication of the Applicant for certificate re-issuing after expiry is done in accordance with the initial identity validation procedure from Section 3.2 hereof.

3.3.4 Identification and authentication for certificate recovery

Certificate recovery is carried out for the reasons and under conditions specified in Section 4.7.1 hereof.

Identification and authentication of the Applicant for certificate recovery is done in accordance with the initial identity validation procedure from Section 3.2 hereof.

3.4 Identification and authentication for revocation request

Fina carries out certificate revocation based on submitted requests. Authentication of the Applicant is done so as to establish the identity of the Natural person - citizen acting as the applicant and whether that person is authorised to submit the request.



Fina carries out identification and authentication of the Applicant submitting the certificate application depending on the form of delivery of the request:

• Submitting the revocation request in person to a registration authority of the Fina RA Network

Identification and authentication is carried out by means of direct identification procedure of the Applicant based on the identification document of the Applicant from Section 3.2.3.3. a) hereof, during office hours of the registration authority of the RA Network.

• Submitting the revocation request by mail or delivery

Identification and authentication of the Applicant is conducted in the registration office of the RA Network based on the copy of the Applicant's identification document specified in Section 3.2.3.3. a) hereof.

• Electronic delivery of the revocation request to the e-mail address

Identification and authentication of the Applicant is done based on the scanned identification document specified in Section 3.2.3.3. a) hereof.

• Submitting the revocation request by phone

Revocation requests made by phone are carried out by calling the Fina’s telephone number published on the website of the repository referred to in Section 2.2 hereof, 24 hours a day, 7 days a week.

The authorised officer who receives the telephone application performs the Applicant identification and authentication procedure based on enquiry and comparison of answers with the records stored in the Fina RA system.

• Submitting the revocation request by fax

Identification and authentication of the Applicant requesting certificate revocation is carried out based on the copy of the identification document of the Applicant referred to in Section 3.2.3.3. a) hereof, submitted by fax together with the revocation request. The fax number is specified in Section 9.11 hereof.



4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1 Certificate Application

4.1.1 Who can submit a certificate application

A certificate application is submitted by Legal persons, unless otherwise provided for in laws and acts adopted thereon.

4.1.2 Enrolment process and responsibilities

Each issuance of a new certificate requires certificate application submission.

Prior to the initial issuance of each certificate, the Subscriber concludes a Subscriber Agreement with Fina, which is signed by the Legal Representative.

The certificate modification application is submitted to the registration offices of the Fina RA Network.

The certificate application may be submitted in electronic form.

4.1.2.1 Certificate Application Process

Certificate application is submitted by the Custodian.

If the application and the agreement are submitted in electronic form, they are signed by an advanced electronic signature

Certificate application is additionally signed by Legal Representative.

If multiple persons have been assigned autonomous and individual representation through the resolution on Legal person's registration with the competent registry or another act if the registration is not stipulated, the application and contract are signed by any person authorised for the representation of the Legal person.

The rules concerning Legal Representatives signing certificate applications are equally valid for paper and electronic form of the application. These rules are stated in Section 3.2.5 hereof.

After receiving and verifying the application data, the application is signed by the Registration Officer from the Fina RA Network and the date of receipt is placed upon it. This procedure verifies that the submitted application has been properly filled in, signed and accepted by the Fina RA Network Registration Officer.

In case the certificate application has been submitted in electronic form, Fina's Centre for the Receipt of e-Applications verifies the application and places a Time-Stamp with the application's time of receipt. The Fina RA Network Registration Officer verifies the application data and validates all advanced electronic signatures on the application.



Following the positive verification of the electronic application, the certificate application is entered into the RA application.

The Applicant's identification and authentication is carried out as described in Section 3.2 hereof.

4.1.2.2 Obligations and Responsibilities in the Certificate Application Process

Subscribers conclude a Subscriber Agreement with Fina whereby they accept the Certificate Policy and terms and conditions of the certification services provision.

The Subscriber Agreement is signed by the Legal representative.

Prior to providing certification services falling within the scope of this CPSWSA-eIDAS, each state administration body enters into a business relationship with Fina by concluding a specific Subscriber Agreement.

In the certificate application process, the Applicants shall submit accurately and entirely filled, as well as duly signed and sealed, certificate application, and the documentation they attach or deliver shall be accurate and complete as well as valid at the time of application submission.

Obligations and responsibilities of the Subscriber are listed in Section 9.6.3 hereof.

Obligations and responsibilities of Fina RA Network are listed under Section 9.6.2 hereof.

The obligations and responsibilities of Fina, as a Trust Service Provider, are listed in Section 9.6.1 hereof.

4.2 Certificate application processing

4.2.1 Performing identification and authentication functions

Identification and authentication of the identity of Natural persons - citizens and the Legal person referred to in the application is conducted pursuant to Chapter 3 hereof.

Upon receiving the certificate application, the Registration Officer from the Fina RA Network proceeds as follows:

• After receiving the certificate application where the issuance of a certificate is requested, the Registration Officer reviews the submitted application due to control measures, pursuant to the procedure described in Sections 3.2.2., 3.2.3. and 3.2.5 hereof,

• If the application is incomplete or it has not been accurately filled in and duly signed, the Registration Officer must reject such an application pursuant to Section 4.2.2 hereof, and then explain to the Applicant how to properly fill in and sign the application,



• The Registration Officer verifies whether the Legal person has already been

registered. If the FINA RA system contains no record of the Legal person's registration, one is made by entering the data from the application and the submitted documentation, by using the Fina RA application and verifying the data by sending enquiries to the national OIB system (if applicable),

• The Registration Officer verifies whether the Custodian or the Legal Representative referred to in the application has already been registered. If the FINA RA system contains no record of the Custodian's registration, one is made by entering the data from the application and the submitted documentation, by using the Fina RA application and verifying the data by sending enquiries to the national OIB system (if applicable),

• The Fina RA Network Officer sets the application status to "prepared" which marks the application's approval in the Fina RA application. This also generates the Distinguished Name (DN) of the entity.

• The Registration Officer signs the order electronically via the Fina RA application, and the order contains verified data from the application and is forwarded to Fina RDC 2015 CA for further processing.

4.2.2 Approval or rejection of certificate applications

Registration Officer of the Fina RA Network checks the data submitted by the Applicant and confirms the accuracy and integrity of information in the certificate application. The Registration Officer from Fina LRA signs off on the successful and correct identification of the Applicant and securely delivers the information to the central Fina RA or rejects the application in case of unsuccessful identification or incorrect submitted information.

The Validation Officer in the central Fina RA carries out the verification of data pursuant to Section 3.2.2.1. and Section 3.2.2.2 hereof and checks for a CAA record for each dNSName in the subjectAltName extension of the Certificate to be issued, according to the procedure in RFC 6844 – DNS Certification Authority Authorization (CAA) Resource Record [20], and follows the processing instructions for any records found.

The Fina CA’s CAA identifying domain is “fina.hr”.

If the Registration Officer or the Validation Officer rejects the certificate application, he or she informs the Applicant thereof in writing or orally, and provides the reasons for the rejection.

The certificate application may be rejected due to:

• inaccurate data, • an incorrectly signed application or agreement, • incomplete or incorrect attached documentation, • non-compliance with the property requirement or the right to use the name of the

domain or server IP address given in the certificate application, • previous inadequate handling and failure to comply with contractual obligations, • legal ban,



• processing instructions from the CAA record, • suspicion of attempted fraud.

4.2.3 Time to process certificate applications

Under normal circumstances, the certificate application processing time is up to five business days from the receipt of the application by the Fina RA Network.

If the Applicant fails to complete the documentation for certificate issuance within 60 days of the date of application submission it is deemed that he or she has withdrawn their certificate application.

4.3 Certificate issuance

Fina RDC 2015 CA issues the certificate after all data verification processes have been performed and after the Registration Officer has approved the certificate application. Certificate issuance is carried out in secure manner to ensure the authenticity of the certificate. For this reason, Fina has implemented measures to prevent forgery of certificates.

Measures against forgery of certificates include:

• usage of prescribed algorithms and parameters and measures of private key protection,

• usage of the prescribed methods of proving the possession of private user keys, • prevention of physical and logical (online) access to the system for issuing certificates

by unauthorized persons, • checking of the integrity of the critical components of the system, • protection of the computer network, • deployment and separation of trusted roles.

4.3.1 CA actions during certificate issuance

4.3.1.1 Issuance of SSL Certificate Level 2 (OVCP)

a) Fina generates the key pair

When Fina generates the key pair, issuance of SSL Certificate Level 2 (OVCP) is performed in the following manner:

• Upon confirmation of the certificate order from the RA application made by the Registration Officer, the FINA CMS generates and deliver the Custodian's authentication log-in data for the Fina CMS,

• The authentication login data is delivered to the Custodian using two separate electronic channels or they are handed to the Custodian by the Registration Officer personally, upon previous direct identification of the Legal Representative,

• Upon accessing Fina CMS from a remote Subscriber location, and the authentication of the Custodian, and the initiation of the procedure through the Fina CMS, the Fina



CMS generates a key pair and the certificate signing request is delivered to Fina RDC 2015 CA,

• Fina RDC 2015 CA certifies the public key by issuing a certificate according to the certificate type SSL Certificate Level 2 (OVCP),

• The Custodian enters the activation data for private key protection using Fina CMS, • Fina CMS delivers the private key and certificate in the PKCS#12 file secured by the

activation data to the Custodian using the secure TLS channel.

b) Custodian generates the key pair at the location of the Subscriber

When Custodian generates the key pair, issuance of SSL Certificate Level 2 (OVCP) at the location of the Subscriber is performed in the following manner:


• The authentication log-in data are delivered to the Custodian using two separate electronic channels or they are handed to the Custodian by the Registration Officer personally, upon previous direct identification,

• The Custodian generates the key pair at the location of the Subscriber pursuant to the Section 6.1.1.2 hereof,

• The Custodian makes a PKCS#10 request at the location of the Subscriber that contains the public key from the generated key pair, and he/she signs the certificate signing request with his/her private key from the same generated key pair,

• The Custodian sends the PKCS#10 certification request using the Fina CMS and the secure TLS channel to the individual Fina RDC 2015 CA,

• Fina RDC 2015 CA certifies the public key by issuing a certificate to the Subscriber according to the certificate type SSL Certificate Level 2 (OVCP),

• The Custodian retrieves the issued certificate via the Fina CMS.

4.3.1.2 Issuance of SSL Certificate Level 3 (OVCP)

Issuance of SSL Certificate Level 3 (OVCP) is performed in the following manner:


• The authentication log-in data are delivered to the Custodian using two separate electronic channels or they are handed to the Custodian by the Registration Officer personally, upon previous direct identification,

• The Custodian generates a key pair in the HSM at the location of the Subscriber pursuant to Section 6.1.1.2 hereof,

• The Custodian makes a PKCS#10 request at the location of the Subscriber that contains the public key from the generated key pair, and he/she signs the certificate signing request with his/her private key in the HSM from the same generated key pair,



furthermore, he/she sends a PKCS#10 certificate request to Fina RDC 2015 CA through the use of a secure TLS channel.

• Fina RDC 2015 CA certifies the public key by issuing a certificate to the Subscriber according to the certificate type SSL Certificate Level 3 (OVCP),

• The Custodian retrieves the issued certificate via the Fina CMS.

4.3.2 Notification of certificate issuance by the CA to other entities

The Custodian is notified of the possibility to retrieve the certificate via e-mail.

The Custodian retrieves the certificate on-line and is notified of the certificate issuance during this online process of retrieving the certificate.

4.4 Certificate acceptance

Certificate acceptance by the Custodian is a prerequisite for the Custodian to use the certificate.

By accepting the certificate, the Custodian accepts that all the data entered in the certificate is accurate and true at the moment of its acceptance, and that they are not misleading.

4.4.1 Conduct constituting certificate acceptance

The Custodian verifies the certificate content pursuant to Fina's instructions during or immediately after the certificate retrieval. In case the Custodian does not accept any part of the certificate, he or she must reject the certificate and immediately notify Fina at [email protected] or in person at the RA Network registration office and list the reasons for the rejection. The Fina RA Network forwards that information to the Central RA. Upon receiving the notification, the Revocation Officer carries out the revocation of the specified certificate following the procedure listed in Section 4.9 hereof.

The Custodian is deemed to have accepted the certificate at the moment of its first use.

In the event that the Custodian fails to use or reject the issued certificate within fifteen days of its retrieval, the certificate is deemed accepted by the Custodian.

The instructions for certificate acceptance can be found on the repository website listed in Section 2.2 hereof. While receiving the authentication data for the retrieval of the certificate, the Custodian also receives the link where the corresponding instructions can be found.

4.4.2 Publication of the certificate by the CA

If the Legal Representative has authorised the public disclosure of the certificate, Fina RDC 2015 CA makes the certificate available in the Fina PKI repository.

Consent for the publication of certificates in the Fina PKI repository is given when concluding a Subscriber Agreement.




The Relying Parties can access the certificate via the website of the repository referred to in Section 2.2 hereof.


It is implied that other entities are notified of certificate issuance by its availability for retrieval in Fina PKI repository.

4.5 Key pair and certificate usage

4.5.1 Subscriber private key and certificate usage

In cases when the Subscriber is in possession of and manages a pair of keys, then the Subscriber commits to:

• Generate key pairs using algorithms stipulated by the ETSI TS 119 312 [12] standardisation document and the key size in accordance with Section 6.1.5 hereof,

• Use the certificate and the accompanying private key solely for the purposes provided herein and in the terms and conditions of certification services provision,

• Use the certificate and the accompanying private key in accordance with the laws and other regulations of the Republic of Croatia and in accordance with Sections 1.4.1. and 1.4.2 hereof,

• From the moment the private key is in the Subscriber’s sole possession, protect the private key from theft, loss, modification, and compromise,

• Use and keep the private key in a manner that prevents its unauthorised use, • When using the private key connected to an SSL certificate level 3 (OVCP), the

private key is used by using the HSM, in accordance with Section 6.2.1., • When using the private key connected to an SSL certificate level 2 (OVCP), the

private key activation is implemented with the adequate activation data, • When using the private key connected to an SSL certificate level 2 (OVCP), the

private key activation is implemented with the adequate activation data, • Use the certificate and the accompanying private key only on servers available

through FQDN or IP address specified in the Subject Alternative Name certificate extension,

• Keep the private key activation data safe, in a protected place separate from the private key,

• Notify Fina as the Trust Service Provider and request certificate revocation in all applicable cases listed in Section 4.9.1 hereof,

• If the private key has been compromised, immediately cease with its use and the use of the pertaining certificate.

4.5.2 Relying party public key and certificate usage

The Relying Party that intends to rely on the certificate issued according to this CPSWSA-eIDAS document should:



• Take care to ensure the appropriate use of the certificate and the limitations of that

use, which have been stated on the certificate or are referred to in the certificate, • Take account of the adequate use and prohibited use of the public key and the

certificate described in Section 1.4 hereof, • Verify the validity period of all certificates in the certificate chain and check the

certificates following the procedure for certificate path validation, pursuant to the IETF RFC 5280 [16] document,

• Verify the certificate revocation status via the OCSP service or on the basis of the last issued CRL, as stipulated herein.

By relying on an expired or revoked certificate the Relying Party loses the warranties provided by Fina as the certification service provider.

4.6 Certificate renewal

Fina performs certificate renewal by generating a new key pair and issuing a new certificate for the existing Legal person whose certificate will soon expire, upon his or her request. The new certificate Distinguished Name (DN) is identical to the certificate Distinguished Name (DN) which is about to expire.

The certificate renewal procedure is described in Section 4.7 hereof.

4.6.1 Circumstance for certificate renewal

See Section 4.7.1.

4.6.2 Who may request renewal

See Section 4.7.2.

4.6.3 Processing certificate renewal requests

See Section 4.7.3.

4.6.4 Notification of new certificate issuance to subscriber

See Section 4.7.4.

4.6.5 Conduct constituting acceptance of a renewal certificate

See Section 4.7.5.

4.6.6 Publication of the renewal certificate by the CA

See Section 4.7.6.




See Section 4.7.7.

4.7 Certificate re-key

Upon identifying and authenticating the Applicant for:

• Routine certificate renewal and new key pair generation, • Certificate issuance following expiry, • Certificate re-issuance after revocation, and • Certificate recovery.

Fina issues a certificate whose Distinguished Name (DN) and other parameters are equal to the parameters of the certificate to which the application refers, but with a new public key, new certificate serial number, new validity period and a new signature by the Fina RDC 2015 CA.

4.7.1 Circumstance for certificate re-key

Routine certificate renewal with the generation of a new key pair is carried out if the Subscriber's certificate is expiring soon, and the Subscriber intends to continue using the service. The certificate is renewed in this manner if all of the following terms and conditions have been met:

• the validity of the certificate has not expired and the certificate expires in less than 45 days,

• the certificate has not been revoked, • Subject data and other attributes contained in the certificate are accurate and

complete at the moment of the routine certificate renewal request.

Certificate recovery is carried out in case of Subscriber’s HSM malfunction, deletion or destruction of the Subscriber's private key, or when the Subscriber, due to some other reason, is not able to use the private key connected to the public key in the certificate, and is carried out before the onset of deadlines for certificate renewal.

The prerequisite for submitting a certificate recovery application is that the certificate is valid, i.e. it has not expired, it has not been revoked and that there is no need to change the Subscriber data in the certificate.

During the period when it is possible to request routine certificate renewal (45 days before certificate expiration), it is not possible to request certificate recovery, rather the Subscriber must request certificate renewal by submitting a certificate application.

In the recovery procedure, Fina RDC 2015 CA shall revoke a certificate whose recovery is requested and shall issue a new certificate.



Certificate issuance after expiry is carried out if the Subscriber's certificate has expired, and the Subscriber intends to continue using the service. Certificate issuance after expiry is not considered as renewal of an existent expired certificate.

A prerequisite for such certificate issuance is that the Subscriber data contained in the certificate has not been modified.

Certificate issuance after expiry is not considered as renewal of an existent expired certificate.

During certificate issuance, after the certificate has expired, the Applicant submits the entire required documentation, as was the case during the initial certificate issuance.

4.7.2 Who may request certification of a new public key

An application for the renewal, recovery or issuance of a certificate after its expiry may be submitted by the Custodian or Legal Representative.

4.7.3 Processing certificate re-keying requests

Certificate renewal and new key pair generation application is submitted in the Fina RA Network, and the identification and authentication of the identity of Natural persons - citizens and the Legal person referred to in the application is conducted pursuant to Section 3.3.1 hereof. The RA Network Officer checks the details in the application and confirms the accuracy and integrity of information in the application. The Fina RA Network registration office approves and rejects applications which were submitted there.

Verification of data in the application is carried out by comparing the data in the application with data in Fina's database of registered subscribers or by using communication channels in accordance with the applicable legislation.

Upon verifying the authenticity and validity of the application, Fina RDC 2015 CA issues a certificate in accordance with Section 4.3.1 hereof.


During the month immediately preceding the certificate expiry, Fina notifies the Custodian of the upcoming certificate expiry, and invite them for a routine certificate renewal and new key pair generation.

Notifying the Custodian of the certificate renewal is done in accordance with Section 4.3.2 hereof.

4.7.5 Conduct constituting acceptance of a re-keyed certificate

Conduct constituting acceptance of a renewed certificate with new key pair generation issued in accordance with Section 4.7.1. is carried out in accordance with Section 4.4.1 hereof.



4.7.6 Publication of the re-keyed certificate by the CA

Publication of the renewed certificate upon new key pair generation issued in accordance with Section 4.7.1. is carried out in accordance with Section 4.4.2 hereof.


Publication of the renewed certificate upon new key pair generation issued in accordance with Section 4.7.1. is carried out in accordance with Section 4.4.2 hereof.

4.8 Certificate modification

Legal persons are required to notify Fina of the modification of data contained in the certificate within seven days and request certificate data modification.

Fina carries out certificate data modification only during validity period of the certificate that has not been revoked.

4.8.1 Circumstance for certificate modification

Circumstances for modifications within OVCP certificates may be modifications referring to the Subject:

• Change of FQDN or IP address, • Change of Legal person’s name or registered office.

The circumstances for modification within the certificate may be modifications to the certificate profiles, as well as modifications to certification systems that affect the content of certificate fields.

4.8.2 Who may request certificate modification

Modifications within an OVCP certificate may be requested by the Custodian or Legal Representative.

4.8.3 Processing certificate modification requests

The certificate modification application is submitted to the Fina RA Network office. The Applicant's identification and authentication is carried out in accordance with the initial identification procedure referred to in Section 3.2 hereof. Application processing and certificate issuance is carried out in accordance with Sections 4.2., 4.3. and 4.4 hereof.

Upon verifying the authenticity and validity of the application, Fina RDC 2015 CA issues a certificate in accordance with Section 4.3.1 hereof.




When issuing certificates in the process of certificate modification, notification of Subscribers is carried out in accordance with Section 4.3.2 hereof.

4.8.5 Conduct constituting acceptance of modified certificate

Conduct constituting modified certificate acceptance is carried out in accordance with Section 4.4.1 hereof.

4.8.6 Publication of the modified certificate by the CA

Publication of the modified certificate is carried out as described in Section 4.4.2 hereof.


Notification of other parties of the modified certificate issuance is carried out in the manner described in Section 4.4.3.

4.9 Certificate revocation and suspension

4.9.1 Circumstances for revocation

Fina revokes a certificate:

• in the event that Custodian or Legal representative requests in writing that Fina revoke the certificate,

• in the event that Custodian or Legal representative notifies Fina that the original certificate request was not authorized and does not retroactively grant authorization,

• in the event of termination of the Subscriber Agreement by the Subscriber, • if there is a reasonable doubt of the private key being compromised or if the private

key or activation data are no longer in the sole possession of the Custodian or Legal person,

• in the event of loss or permanent unavailability of the private key, • in the event that Fina obtains evidence that the certificate was misused or in the

event of an official notification on the certificate use for illegal purposes, • in the event that Fina is made aware that a Subscriber has violated one or more of its

obligations under the Subscriber Agreement, Terms of Use, Certificate Policy [22] or this CPSWSA-eIDAS document,

• in the event that Fina is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the certificate is no longer legally permitted,

• in the event of a change in the information contained in the certificate, • if the certificate has not been issued in accordance with Certificate Policy [22] or this

CPSWSA-eIDAS document,



• in the event that Fina determines that any of the information appearing in the

certificate is inaccurate or misleading, • in the event that Fina ceases operations for any reason and has not made

arrangements for another trust service provider to provide revocation support for the certificate,

• in the event that Fina′s right to issue certificates under these Requirements expires or is revoked or terminated, unless Fina has made arrangements to continue maintaining the CRL/OCSP repository,

• in the event that Fina is made aware of a possible compromise of the private key of the Fina′s CA used for issuing the certificate,

• in the event that Fina is made aware that technical content or profile of the certificate does not provide an appropriate level of trust to Application Software Suppliers or Relying Parties,

• in cases when this is required by law or other regulations, • in cases when revocation is required by Certificate Policy [22] or this CPSWSA-eIDAS

document.

4.9.2 Who can request revocation

Application for OVCP certificate revocation is submitted by the Custodian or the Legal Representative.

The RA Network may file a certificate revocation application.

Fina may revoke a certificate based on an authenticated official notification by a competent body.

Subscribers, Relying Parties, Application software suppliers and other third parties may file Certificate Problem Report related to certificate usage to Fina, such as the private key being compromised, certificate misuse, using certificates for illegal purposes, inappropriate use of certificates and other fraudulent actions.

4.9.3 Procedure for revocation request

Immediately upon the occurrence of any reason for revocation listed in Section 4.9.1 hereof, the certification revocation requests is filled in accurately and entirely, as well as signed and submitted as soon as possible in one of the following manners:

• By personal delivery to a registration RA Network office during office hours, • By mail or courier at the RA Network office address, • By electronic delivery to the e-mail address listed in Section 9.11 hereof, 24/7, • By fax to the number specified in Section 9.11 hereof.

On the basis of an accurately filled out and signed revocation application, and Applicant's identification and authentication, Fina revokes the certificate and notify the Custodian thereof, and if applicable, the Legal person with which the Custodian is associated.



Certificate revocation request can also be submitted by telephone, 24 hours a day, 7 days a week, by calling Fina’s telephone number published on the web pages of the repository referred to in 2.2 hereof.

If the certificate revocation request is submitted by telephone, the Revocation Officer does authentication of the submitter of request, who authenticates himself with his name and surname, and if the certificate is associated with business entity, by quoting the name of that business entity and with the knowledge of password that was provided during the submission of the application for certificate issuance. After successful authentication the Revocation Officer gets the certificate information from the submitter of the request. The certificate information is the serial number of the certificate, but in case the submitter has no such information, other certificate information related to the certificate type or date of certificate issuance will be provided. After identifying the certificate, the requester confirms its request for revocation of the identified certificate. The Revocation Officer verifies whether the submitter has the right to request the certificate revocation, and in case he has that right, the Revocation Officer revokes requested certificate and notifies the Custodian thereof, and if applicable, the Legal person with which the Custodian is associated.

After revoking a certificate, Fina RDC 2015 CA issues and publishes a CRL, while the information on the certificate revocation status also becomes available on the OCSP service.

In the event that third party filled a Certificate Problem Report, Fina shall verify the merits of the report related to the certificate use issue and shall adopt a decision on steps to be taken regarding the submitted report.

Issues related to certificate use are reported to the e-mail address referred to in Section 9.11.

4.9.4 Revocation request grace period

Applicants requesting certificate revocation referred to in Section 4.9.2 hereof, should submit an application for certificate revocation as soon as reasonably practicable from the occurrence of the reason of revocation referred to in Section 4.9.1.

4.9.5 Time within which CA must process the revocation request

The Revocation Officer and the Registration Officer may, if necessary, request and collect additional data which can influence a revocation decision. If the Revocation Officer is unable to reach a decision on certificate revocation based on the collected data, he or she notifies the PMA who will in this case reach a decision on certificate revocation.

The Revocation Officer revokes the certificate or performs other necessary steps as soon as reasonably practicable and no later than 24 hours from reaching the decision on certificate revocation.

Immediately upon the certificate revocation, Fina RDC 2015 CA updates the certificate database and issues a new CRL without delay.



4.9.6 Revocation checking requirement for relying parties

Reliance on a revoked certificate can cause personal or business damage to the Relying Party. Therefore, before relying on a certificate, the Relying Party checks the certificate status with the aim of determining whether it has been revoked in accordance with Sections 4.5.2., 4.9.9. and 4.9.10 hereof. If the Relying Party is not able to acquire information on the certificate status at the moment, the Relying Party should not rely on such a certificate.

4.9.7 CRL issuance frequency

Fina RDC 2015 CA issues and signs Fina RDC 2015 CRL. CRL is published immediately upon the certificate revocation as well as every six hours from the previous CRL issuance. Revocation status information includes information on the status of certificates at least until the certificate expires.

The time frame for the next CRL issuance (field value Next Update) is 24 hours from the last CRL issuance at the latest.

4.9.8 Maximum latency for CRLs

Immediately upon the certificate revocation, Fina RDC 2015 CA updates the certificate database and issues a new CRL without delay. Maximum latency for CRL from the moment of its issuance to the moment of its publication in regular circumstances is two minutes.

4.9.9 On-line revocation/status checking availability

Fina RDC 2015 CA supports online check for issued certificate revocation status via Fina OCSP service compliant with the IETF RFC 6960 [17] recommendation.

Information on certificate revocation status via Fina OCSP service is available in real time.

Fina OCSP service address is http://ocsp.fina.hr, and it is contained in the Authority Information Access extension of each certificate.

CRL is primarily available through HTTP Internet address on the server of the corresponding repository, and secondarily through LDAP directory, as described in Section 4.10.1 hereof. Data on access points for CRL content retrieval is contained in each issued certificate.

4.9.10 On-line revocation checking requirements

In order to use the Fina OCSP service the Relying Party must have an application solution which can use the OCSP service referred to in Section 4.10.1 hereof by using the GET and POST method.

In order to retrieve the CRL, the Relying Party must have Internet access and be able to use applications or solutions which are compatible with CRL retrieval from web pages and protocols listed in Section 4.10.1 hereof.




4.9.11 Other forms of revocation advertisements available

No stipulations.

4.9.12 Special requirements related to key compromise

In case of receiving certificate revocation applications or receiving a Certificate Problem Report on issues related to the certificate use, Fina shall be able to revoke the subject certificate and the information on the private key compromise and the reason for revocation shall be contained in the notification of the certificate revocation status.

4.9.13 Circumstances for suspension

Fina does not suspend OVCP certificates.

4.9.14 Who can request suspension

Not applicable.

4.9.15 Procedure for suspension request

Not applicable.

4.9.16 Limits on suspension period

Not applicable.

4.10 Certificate status services

4.10.1 Operational characteristics

Fina informs of the certificate revocation status through providing OCSP service or CRL publication. Information on the status of individual certificates is available at least during the entire certificate validity period.

It is recommended to Relying Parties that they use Fina OCSP service for certificate status verification, and the status verification through retrieval of a CRL may be used as an alternative verification method in case of OCSP service unavailability or if the Relaying Party's application supports the verification of certificate status only via CRL.

Fina OCSP service address is http://ocsp.fina.hr, and it is entered in the Authority Information Access extension of all certificates issued by Fina RDC 2015 CA.

CRLs is published on the Internet server and in the public directory of the Fina RDC 2015 CA repository. Consolidated CRL is published on the Internet server, and consolidated and segmented CRL is published in the public directory.




CRL publication addresses are contained in the CRLDistributionPoints extension of every issued certificate.

If the application of the Relying Party supports using segmented CRL, the application retrieves a certain segment of the segmented CRL from the public directory.

If the application of the Relying Party does not support using a segmented CRL, the CRL is retrieved in the following order:

1. The application retrieves the consolidated CRL from the Internet server,

2. If the Internet server is not available, the application retrieves the consolidated CRL from the public LDAP Directory.

4.10.1.1 Retrieval Addresses for CRL Fina RDC 2015 Certificates

The consolidated CRL address for Fina RDC 2015 certificates on the Internet server is:

http://rdc.fina.hr/RDC2015/FinaRDCCA2015.crl.

The consolidated CRL address for Fina RDC 2015 certificates in the public directory is:

ldap://rdc-ldap2.fina.hr/CN=Fina RDC 2015, O=Financijska agencija, C=HR?certificateRevocationList;binary

The segmented CRL address for Fina RDC 2015 certificates in the public directory is:

ldap://rdc-ldap2.fina.hr/cn=CRLx,ou=RDC,o=FINA,c=HR?certificateRevocationList %3Bbinary.

The “x” designation in cn=CRLx designates a CRL segment.

4.10.2 Service availability

CRL and OCSP service is available 24 hours a day, seven days a week. In the event of system failure, circumstances beyond Fina’s control or force majeure, the service shall be available in accordance with the Business Continuity Plan.

Service access points for certificate validity check are specified in Section 4.10.1 hereof.

4.10.3 Optional features

No stipulations.

4.11 End of subscription

If a Subscriber terminates the Agreement before the certificate expiry date, Fina RDC 2015 CA shall revoke all certificates subject to such Agreement.

http://rdc.fina.hr/RDC2015/FinaRDCCA2015.crl

ldap://rdc-ldap2.fina.hr/CN=Fina%20RDC%202015,%20O=Financijska%20agencija,%20C=HR?certificateRevocationList;binary

ldap://rdc-ldap2.fina.hr/CN=Fina%20RDC%202015,%20O=Financijska%20agencija,%20C=HR?certificateRevocationList;binary

ldap://rdc-ldap2.fina.hr/cn=CRLx,ou=RDC,o=FINA,c=HR?certificateRevocationList%3Bbinary

ldap://rdc-ldap2.fina.hr/cn=CRLx,ou=RDC,o=FINA,c=HR?certificateRevocationList%3Bbinary



4.12 Key escrow and recovery

Safe storage of Subscriber private keys for OVCP certificates is not applied.



5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

Fina ensures the adequate protection of the property used for certificate provision services and, to that aim, keeps a comprehensive list of that property with the accompanying classification in accordance with the risk assessment.

Physical protection measures, procedures implemented by Fina in protecting the system for certificate issuance (hereinafter referred to as: "certification system"), as well as system, management and operational procedure controls in Fina PKI are internal and the details thereof are not publicly disclosed.

5.1 Physical controls As a Trust Service Provider, Fina implements certification system physical protection measures aimed at minimising risks related to physical protection and in accordance with Fina's business policy and laws in force.

5.1.1 Site location and construction

Fina's primary certification production system is situated on the primary production site inside Fina's building, on separate, protected premises envisaged for this purpose, subject to implementation of multiple levels of physical and technical protection.

The purpose of Fina's certification system on secondary location is to take over the functions of the primary production certification system in case of primary system's failure until its recovery and restoration of its services. Certification system on secondary location is situated on Fina's remote backup site and it meets equal or higher security requirements compared to the primary system.

The management of Fina Root CA, its subordinate Fina CAs, Central Fina RA system, public directory and electronic archive is carried out from the Fina PKI protected premises.

The Fina PKI protected premises are internally divided into security zones:

Secure premises accommodating Fina's certification systems at the primary and secondary location is hereinafter be referred to as: the "Fina PKI protected premises".

5.1.2 Physical access

Physical access to the certification system on the Fina PKI protection premises and accompanying security zones within these premises is achieved with the dual control of passage of Fina PKI authorised personnel and in accordance with their roles and authorisations.

Persons who are not authorised to physically access the certification system may access it only in the company of authorised persons and in accordance with the Fina internal procedures.



Each access to the certification systems is recorded.

Physical access to the certification system in the Fina PKI protected premises (Fina RDC 2015 CA system, the central Fina RA system, the public directory and electronic archive) may be achieved only by passing through access zones.

Physical access to the paperwork collected during the registration of natural persons and business entities by the Fina RA Network is controlled by allowing access to locked filing cabinets which contain the documentation. The paperwork collected by the Fina RA Network during registration can only be accessed by Registration Officers and authorised persons of the Fina RA Network.

The archives where the Fina PKI paperwork is stored can only be accessed by authorised persons from the Fina. Fina's archives are equipped with video surveillance and are under constant supervision of the security company that provides constant physical protection of the facility.

5.1.3 Power and air conditioning

Devices and premises where Fina RDC 2015 CA, Fina RA system and repository, as well as technical protection systems, are located is continuously supplied with electricity and air-conditioning sized to ensure appropriate operational conditions even in case of external supply interruptions.

Backup power has been ensured by a device for continuous power supply in combination with a diesel engine which ensures the continuous and reliable operation of the certification system until the primary power supply has been restored.

Air conditioning devices have been installed on all premises with the certification system equipment for the maintenance or proper work conditions.

5.1.4 Water exposure

Fina's certification system equipment is stored at the premises which are ensured against floods and placed on elevated floors.

The archives of paper documents of Fina PKI have been stored at the premises where the facility physical structure, elevated floors and metal shelves for the documentation, protect the archived material from floods and water and drain pipe ruptures.

5.1.5 Fire prevention and protection

A fire alarm and protection system has been installed at the Fina PKI protected premises pursuant to the fire safety regulations. The automatic system uses extinguishing agents for extinguishing fire on electric installations and the IT equipment. The Fina PKI protected premises have a stable fire alarm system and fire detectors.



The Fina RA Network premises have been secured pursuant to the provisions of the Fina's internal fire protection rules.

Fina archives which materials in paper form of Fina PKI have been equipped with a fire alarm system and are secured in accordance with the provisions of the Fina's internal fire protection rules.

5.1.6 Media storage

Media containing archived and backup copies of the Fina PKI data in electronic form, the repository content copies and software equipment backup copies has been safely stored at two separate secured locations in order to protect it against damage, theft or unauthorised access. The media containing data has been stored at the Fina PKI protected premises of the primary production system and at a backup location.

Persons with the System Operator trusted role are authorised to work with the data backups.

5.1.7 Waste disposal

Documents and data in paper or electronic form located at the Fina PKI protected premises, or containing confidential information, which do not require archiving, are safely removed and destroyed.

Waste disposal from the Fina PKI protected premises is effected under the supervision of Fina PKI authorised persons.

All confidential documents and data are physically destroyed at the location before being disposed of in such a manner that this information cannot be reconstructed.

Documents and data in paper or electronic form which do not require further archiving are safely removed from the archive system and destroyed.

Destruction of media which contain confidential data and destruction of data and keys connected to the HSM modules is conducted according with Fina's internal procedures for destruction of data and cryptographic equipment. Such data deletion or destruction of the HSM module data is carried out prior to their possible servicing or reparation.

Fina disposes of all waste material generated on its premises and office space pursuant to the internal work instructions and procedures for ecological waste management.

Methods for destroying private keys are described in Section 6.2.10 hereof.

5.1.8 Off-Site backup

Backup copies of Fina RDC 2015 CA, central Fina RA system, repository content and archive in electronic form, backups of programming equipment are stored on a backup location in the Fina PKI protected premises.



Backup copies stored on protected premises at a backup site, with respect to their original forms, are stored using the equal or a higher security level of the applied physical protection measures.

5.2 Procedural controls

5.2.1 Trusted roles

Information system management, management of the certificate management system, and Fina PKI operation supervision tasks are performed in separate organisational sections of Fina.

Fina ensures that all authorised persons performing tasks related to Fina CAs are assigned to appropriate trusted roles.

Trusted roles are assigned to authorised employees of Fina's competent organisational sections, and they represent a foundation of trust within Fina PKI. Each trusted role is documented by a clearly defined description of tasks and responsibilities.

The description of trusted roles and the corresponding job descriptions, authorisations and responsibilities for each role are given in Fina's internal documents. The corresponding lists indicate the Fina employees who have been assigned trusted roles.

5.2.2 Number of persons required per task

Fina counts on a sufficient number of regular employees with knowledge, experience and qualifications required in Fina PKI for the provision of services falling within the scope of this CPSWSA-eIDAS.

Access and work in the Fina PKI protected premises is performed solely in the presence of at least two authorised persons from Fina PKI who have permission to access the system located in the Fina PKI protected premises.

The number of employees with the corresponding trusted roles for performing specific tasks in subordinate Fina CAs is given in corresponding Fina's internal documents.

5.2.3 Identification and authentication for each role

When logging into critical applications and services within Fina PKI, the person accessing the application or service is identified and authenticated. The person’s identification and authentication is carried out by means of an adequate authentication method. Access and usage of the application and services in the Fina PKI is allowed only to authorised persons pursuant to their allocated trusted role.

Identification of authorised persons of Fina PKI and determining access rights for the performance of individual tasks in Fina PKI is done by using security procedures and the verification process.



Authorised persons with trusted roles in Fina PKI must undergo authentication before accessing Fina RDC 2015 CA or the Fina RA system. For this purpose authorised persons of Fina PKI are given appropriate means for authentication. Before being given the means for authentication the indicated employees must meet the requirements referred to in Section 5.3 hereof.

The means for authentication are:

• Access control cards for accessing the Fina PKI protected security zone, while access permissions are granted only to authorised persons with trusted roles in Fina PKI,

• Certificates on secure cryptographic devices which are given only to authorised persons in Fina who have trusted roles in Fina PKI,

• A user name and password or a certificate on a secure cryptographic device for registering into the operation systems of Fina RDC 2015 CA systems are given to authorised persons in Fina with trusted roles in Fina PKI,

• control cards of the cryptographic module are only given to authorised persons in Fina with trusted roles in Fina PKI pursuant to the roles referred to in Section 5.2.1 hereof.

Each of the referred means of authentication has been personalised for the individual authorised person. The use of the indicated means of authentication has been limited to the tasks and system for which the individual trusted role has been authorised.

The Security Officer is responsible for verifying the identity of the person with a trusted role in Fina PKI.

During the use of critical applications and services, all activities of the registered person are duly logged, stored and saved.

5.2.4 Roles requiring separation of duties

The terms of reference for the authorised personnel with trusted roles in the Fina RDC 2015 CA system are based on the principle of the separation of duties and allocation of minimal user rights which ensure the undisturbed performance of allocated tasks.

The following rules are applied through the separation of duties:

• the Security Officer, the Registration Officer and the Validation Officer is not allowed to perform the duties of the System Auditor,

• the System Administrator is not allowed to perform the duties of the Security Officer or System Auditor.



5.3 Personnel controls

5.3.1 Qualifications, experience, and clearance requirements

All requirements for adequate professional qualification for each trusted role are taken into account at the time of personnel employment with Fina PKI.

Before starting to work at Fina PKI, the candidates must have appropriate expertise, experience, qualifications and education in the field of cryptographic technologies, protection of computer systems, information security and personal data protection in the domain of their own scope of work within Fina PKI.

While hiring new employees, Fina tests the candidates in order to evaluate their quality and competence for performing trusted roles in the Fina PKI system.

The Fina PKI personnel with trusted roles may not be in any conflict of interest which would endanger the operation of the Fina PKI system.

5.3.2 Background check procedures

Before hiring new candidates for work at Fina PKI, Fina conducts psychological testing of the personnel in order to assess their adequacy in relation to the tasks which they will perform.

Before starting to work on Fina PKI tasks, the candidate submits the clearance certificate issued by the competent municipal court stating that there are no pending criminal proceedings against the applicant, i.e. that no decision on investigation has been rendered, no effective indictment has been issued, no non-final judgement imposing a sentence has been passed for criminal offences nor has a criminal order been issued.

By signing the employment contract every employee commits to keep all disclosed confidential information strictly confidential.

5.3.3 Training requirements

Prior to starting work in Fina PKI, the personnel of Fina PKI and the Registration Officers from the Fina RA Network undergo training in accordance with their future tasks.

Fina PKI personnel with trusted roles working on the Fina RDC 2015 CA system is educated and trained in accordance with their trusted roles.

Personnel training and education for persons with trusted roles working on the Fina RDC 2015 CA system includes:

• Fina RDC 2015 CA and Fina RA security principles and mechanisms, • Security awareness, • CA software used in the Fina RDC 2015 CA system, • Tasks related to the trusted roles which will be performed in the Fina RDC 2015 CA

system,



• Procedures for accident recovery and the continuation of business.

Training for Registration Officers in the Central Fina RA and Fina LRA includes:

• Certificate basics, • Types of certificates issued by Fina RDC 2015 CA and their area of use, • Ways to register Subscribers for work in the Fina RA and Fina CMS applications • Security awareness, • Information which needs to be given to Subscribers.

5.3.4 Retraining frequency and requirements

Information Security Awareness course takes place annually for all Fina PKI employees.

Employees with trusted roles in Fina PKI have the obligation to improve their skills and to acquire new knowledge in their area of expertise through self-education or organised internal and external training, and about that the records are kept.

The knowledge of Fina RA Network employees, especially in terms of tasks they perform, is refreshed once every year.

5.3.5 Job rotation frequency and sequence

Not applicable.

5.3.6 Sanctions for unauthorised actions

Not complying with the laid out measures for authorised persons when working in Fina PKI is subject to violation of work duties under the Collective Agreement, and potential penalties are determined in a disciplinary procedure.

In case of unauthorised actions by contractual partners, provisions defined under the Contract with the contractual partner are applied.

5.3.7 Independent contractor requirements

For independent contractors performing a part of certification services for Fina, the same requirements for work in Fina PKI apply as for internal employees.

The requirements for the suppliers of goods and services for Fina PKI are regulated by internal documents governing work with suppliers. The access of external contractors to IT assets in Fina PKI is approved exclusively pursuant to an agreement for only that IT asset that is the subject of the agreement and only for the activity listed in the agreement.

5.3.8 Documentation supplied to personnel

Each employee has been given access to the documentation necessary for the performance of their tasks, which includes internal and external education materials and work instructions



and procedures for performing certain tasks in Fina PKI pursuant to the allocated trusted or Subscriber role and the corresponding authorisation.

5.4 Audit logging procedures

5.4.1 Types of events recorded

All important events in Fina PKI systems related to certification issuance are recorded as revision records in audit logs in electronic or paper form. Revision records contain:

• Date and time of the event, • Type of event, • Identity of the person or system unit responsible for the action, • Success or failure of the monitored event.

Date and time that are used for electronic audit logs, servers in Fina PKI is aligned hourly with the NTP server that is synchronised with the source of the exact time and has a discrepancy of +/-1 regarding the UTC time.

Audit logs contain records in electronic or paper form of all events in Fina PKI related to:

• Life-cycle management of CA keys Fina RDC 2015 CA, • Life-cycle management of HSM modules that protect the Fina RDC 2015 CA private

key, • Life-cycle management of Subscriber keys generated by Fina, • Life-cycle management of certificates issued by Fina RDC 2015 CA, • Registration of a natural and Legal person, • Security events, including system booting and switching off, system failure and

hardware malfunction, firewall and router activities and system security settings modifications.

Data and events recorded in the Fina PKI logs are described in Fina's internal documents.

5.4.2 Frequency of processing log

The procedure for log review encompasses:

• Review of audit log items created after the latest revision, • If necessary, the preparation of a short report containing explanations of important

events. These reviews include a damage check of audit logs and a brief control of all the records with detailed research of irregular events recorded in the log.

Fina RDC 2015 CA system logs and their pertaining HSM modules reviews are carried out by the System Auditor. Fina RDC 2015 CA audit logs and their pertaining HSM modules reviews are carried out regularly, on a daily basis, on business days and in emergency



cases. The audit logs review is recorded in paper or electronic form, and it is kept by a person with the System Auditor trusted role.

Analysis of other audit logs is carried out, if necessary, by the authorised Fina PKI employees.

In case of irregularities or errors relating to security, the person authorised for audit log review makes a report on the analysis of the audit logs and further necessary activities. In case of an unauthorised activity Fina's internal procedures are implemented.

All actions carried out based on the audit log analysis are documented.

5.4.3 Retention period for audit log

Audit logs with records referred to in Section 5.4.1. are kept for at least 10 years from the expiration of certificate to which the logs refer.

5.4.4 Protection of audit log

Audit logs in Fina PKI are protected by mechanisms and procedures ensuring the confidentiality and integrity of logs and not allowing records modification, nor easy records deletion or destruction.

The protection of integrity of critical audit logs of the Fina RDC 2015 CA for issuing certificates is ensured during the generation of those records.

Confidentiality of all audit logs is ensured by controlling access to the system and the right to read audit log records.

Access to audit logs is limited to authorised Fina PKI employees, i.e. to persons with the roles of System Auditor, Security Officer and System Administrator in combination with controls of physical access to Fina PKI protected premises and security controls of access to system data.

Audit logs of all systems in Fina PKI, that contain data mentioned in Section 5.4.1 hereof are, after the period of retention on systems where they were made, archived and protected pursuant to procedures described in Section 5.5.3 hereof.

Audit logs recorded in paper form, such as Records for monitoring entries and exits into and from Fina PKI protected premises are protected from the unauthorised review, deletion, modification or destruction using usual methods for the protection of paper documents.

5.4.5 Audit log backup procedures

New audit logs in Fina PKI are backed up on a daily basis, and their backup copies are stored and stored within the primary production Fina PKI protected premises. In addition, audit log file backups in Fina PKI are stored on media for data storage in secondary protected premises on a remote backup site, pursuant to Section 5.1.8 hereof.



The procedures for creating audit log backups are described in more detail in the Fina's internal documents.

5.4.6 Audit collection system (internal vs. external)

The Log Collection System for all logs in Fina PKI is an internal system in which log systems are collected through the combination of automatic and manual processes which are carried out on the Fina PKI servers and which are initiated and monitored respectively by the Fina PKI employees with trusted roles.

The manual processes of audit log collection refers to the up-to-date recording of the Records for monitoring entries and exits into and from the Fina PKI protected premises.

5.4.7 Notification to event-causing subject

In case of detecting a significant event log in the Fina PKI operation related to a particular Subscriber or other participant, Fina reserves the right to decide on the notification of the Subscriber or other participant causing the event.

5.4.8 Vulnerability assessments

Fina carries out regular risk assessment of the information property, vulnerability assessment for identified public and private addresses and penetration testing.

Information risk assessment is carried out once every year. The system vulnerability assessment for identified public and private addresses of Fina PKI is carried out once every quarter. Penetration testing is carried out once every year. Risk assessment and vulnerability assessment, and the penetration testing is carried out after significant changes.

5.5 Records archival

5.5.1 Types of records archived

Fina PKI stores in its archives data specified below, which may come in electronic or paper form:

• Certificate Policy, • Certification Practice Statements, • Terms and conditions of certification services provision, • Contracts related to certification services provision, • Data connected to Fina RDC 2015 CA key pair generation and pertaining certificate

issuance, • Data and accompanying documentation collected in the natural and Legal person

registration procedure, • Certificate application data submitted by the Subscriber,



• Certificates and data related to life-cycle of individual certificate, including all

applications and reports for certificate revocation and accompanying executed actions,

• Records of revoked certificates, information on certificate revocation and pertaining documentation,

• log records referred to in Section 5.4.1 hereof, • other Fina's internal documents.

Each archived record contains data indicating the time referring to it.

More specific provisions relating to archived records types and locations of Fina PKI archive are given in Fina's internal documents.

5.5.2 Retention period for archive

Fina keeps all archived data and documentation for at least 10 years from the expiration of certificate to which it refers.

5.5.3 Protection of archive

Fina RDC 2015 CA system documentation archived in paper form is stored in Fina PKI protected premises. Upon request, archived records are made available to authorised Fina PKI persons, under dual control.

Documents archived in paper form which were collected during the procedure of natural and Legal persons registration are stored on Fina’s protected archive premises which are under constant supervision by a security service, and the access to the archived documentation is made available to Fina PKI authorised persons and the employees in charge of Fina’s archive. Thereby, the archive is protected from unauthorised review, modification or deletion.

Archived records in electronic form referred to in Section 5.5.1 hereof are stored on appropriate data archiving media in Fina PKI protected premises. Archived records are protected by mechanisms and procedures ensuring confidentiality and integrity of the logs and not allowing records modification, nor easy records deletion or destruction. Confidentiality of archived records in electronic form is protected by encryption, and the integrity of records by a digital signature. Upon request, archived records are made available to authorised Fina PKI persons, under dual control. At least once a year, Fina PKI authorised persons check archive integrity, and if the archive is damaged, it is renewed by a backup copy.

Archived Fina PKI documents and data about the operation of the system are on request made available for the purposes of legal proceedings with aim of providing evidence of the correct provision of services.



5.5.4 Archive backup procedures

Backup copies of records archived in electronic form referred to in Section 5.5.1 hereof are stored in the secondary protected premises on a backup site with equal or higher level of protection comparing to Fina PKI protected premises on the primary location.

Access to backup copies of archived records in electronic form is granted only to Fina PKI authorised employees, under dual control.

5.5.5 Requirements for time-stamping of records

No stipulations.

5.5.6 Archive collection system (internal or external)

Archived records are collected in a way which depends on the type of data and documents.

Fina RDC 2015 CA system documentation in paper form is stored manually and archived internally in Fina PKI protected premises.

Documentation on registered natural and Legal persons in paper, which was collected and created in Fina RA Network, is collected manually and archived internally.

Records in electronic form referred to in Section 5.5.1 hereof are collected automatically and archived internally in Fina PKI protected premises on the primary location and on the secondary protected premises on the backup location.

5.5.7 Procedures to obtain and verify archive information

Access to archived records is granted only to persons with authorised access to archived data. Access to data archived in protected premises, under dual control.

Archived data are verified by their integrity control, or by the verification of the digital signature on the archived data.

Archived data in electronic form are compared to the pertaining backup, if necessary.

5.6 Key changeover

In order to ensure the continuity regarding certification services, Fina shall sufficiently in advance generate a new pair of Fina RDC 2015 CA keys. Also, Fina RDC 2015 CA shall sufficiently in advance generate a new pair of CA keys and in case this change is required by the security level of cryptographic algorithm of the private CA key in use.

Fina RDC 2015 CA signing key pair shall be generated in a way described in Section 6.1 hereof. New Fina RDC 2015 CA certificate with a newly generated public key shall be signed by a Fina Root CA private key.



Fina RDC 2015 CA shall duly notify Fina PKI participants about the planned signing keys modification on the repository web-page referred to in Section 2.2 hereof. The new Fina RDC 2015 CA certificate shall be made available to Fina PKI participants via public directory and repository web-pages.

5.7 Compromise and disaster recovery

5.7.1 Incident and compromise handling procedures

Fina continuously monitors the operation of the Fina PKI system and in case of system failure or incident, timely and coordinated response to the reported event is performed in accordance with the internal procedure.

Fina has a Business Continuity Plan for Fina PKI which regulates the procedures in cases of:

• Natural disaster, • Attack, robbery or building blockade, • IT infrastructure destruction on the primary production site, • IT infrastructure unavailability on the primary production site due to hardware or

software malfunction of a larger scale, • Unavailability of workers, • Termination of services by the supplier, • Loss or compromise or alleged compromise of Fina RDC 2015 CA private key.

Procedures that should be undertaken for the purpose of recovery and establishment of initial security settings of the RA system, archive and repository is encompassed by internal plans.

In case of natural or other disasters, the provisions of the Ordinance on work safety are applied accordingly.

The internal plans also include procedures to be undertaken in order to recover and establish RA's, archives and repositories original security state.

Upon occurrence of some of the aforementioned incidents, the Business Continuity Plan shall also prescribe measures to prevent the repetition of such incident, where such measures are feasible. Selecting measures to prevent incident repetition will be made after analysing the cause and effect of the incident.

Notification in case of the aforementioned disasters is described in the adequate procedures in cases of natural disasters.

Notification in case of compromise or alleged compromise of the Fina RDC 2015 CA private key is described in Section 5.7.3 hereof.

The Business Continuity Plan is revised once a year.



5.7.2 Computing resources, software and/or data are corrupted

Fina certification system is based on reliable hardware and software components, and system critical operations are supported with redundant components.

To ensure availability of external access to Fina PKI services, Fina has redundant network connections.

Functionality, proper work and timely damage removal of certification system components is ensured under support and maintenance with equipment suppliers.

The Business Continuity Plan for Fina PKI regulates procedures for certification system recovery in case of malfunction or damage of equipment and network resources, as well as data recovery.

Backup of electronic records created during the operation of Fina PKI system is made on a daily basis and submitted periodically in the protected premises on a backup site.

5.7.3 Entity private key compromise procedures

In case of private key compromise Fina RDC 2015 CA, Fina shall immediately stop the use of the compromised Fina RDC 2015 CA private key and it shall inspect the circumstances of the key compromise event. If the key compromise event is confirmed, Fina shall decide on the revocation of the CA certificate associated with the compromised key and Fina Root CA shall revoke that CA certificate.

Fina shall notify the following Fina PKI participants of the Fina RDC 2015 CA certificate revocation:

• Fina RA Network • Subscribers, • Relying Parties.

After determining and eliminating the causes responsible for CA key compromise, Fina shall, if possible, take necessary measures to stop the recurrence of such event. Depending on the founded causes of key compromise, Fina may decide to temporarily move to production from the secondary location.

For Fina RDC 2015 CA whose certificate has been revoked, Fina shall organise a new CA key pair generation ceremony and Fina Root CA shall issue a new CA certificate for that new public CA key.

Fina RDC 2015 CA shall, by using the new private CA key, issue certificates to existing registered subjects and shall sign all further information on certificate revocation by using the new key. New CA certificate shall be available to the participants in Fina PKI in the same manner as the previous CA certificate, and in accordance with the description referred to in Section 2.2 hereof.



In case the used cryptographic algorithms and parameters stop providing the required security and protection, Fina shall, if possible, duly communicate this to:

• Fina RA Network, • Subscribers, • Relying Parties.

Fina shall consider the possibility of using other appropriate recommended security cryptographic algorithms and it shall, if possible, make a decision about the use of another algorithm. Fina shall make specific plans and procedures that will necessarily involve the revocation of all certificates that are affected by cryptographic algorithms and parameters whose security is compromised. About those plans and deadlines for implementation Fina will inform Subscribers and Relying Parties thereof, and it shall carry out planned activities in order to continue providing services to Subscribers.

5.7.4 Business continuity capabilities after a disaster

The Business Continuity Plan defines procedures for business continuation after a disaster. Depending on the type of disaster, Fina shall continue providing certification services on its primary certification production system or it shall continue service provision on its secondary certification system until the recovery of the primary production system.

Business continuity strategy regulates the requirements and transformation of trust services to the secondary certification system.

5.8 CA or RA termination

With regards to the planned termination of certificate services provision, Fina shall:

• Inform all subscribers, relying parties and the central state administration body responsible for economy at least three months before the planned termination of certificate services provision,

• Make all possible efforts to ensure the continuation of certificate services provision with another Trust Service Provider, and shall deliver all documentation collected in the Subscriber registration process as well as all documentation on issued certificates to that service provider,

• transfer to that service provider its obligation to enable trusted parties, within reasonable time, to have the availability of Fina's CA certificates with the public keys of Fina CAs as well as the availability of other certificates with public keys of Fina’s Trusts services,

• transfer to that service provider its obligation to provide the availability of CRLs for all revoked Subscriber’s certificates and CA certificates of those Fina CAs that cease its operations,

• transfer to that service provider its obligation to provide the information of certificate revocation status of Subscriber’s and Fina CA certificates through OCSP service,

• revoke all issued certificates,



• revoke the CA certificates and destroy their related private keys of those Fina CAs

that cease its operations.

In case of the termination of certification services provision, Fina shall archive, protect and store the records according to the provisions referred to in Section 5.5 hereof to make those records available for evidence in court, administrative or other proceedings in accordance with applicable provisions of legislation, or Fina shall enter into an agreement with another entity with respect to archiving, protection and keeping of records.



6 TECHNICAL SECURITY CONTROLS

This Chapter describes the protection measures undertaken with the aim of achieving the required security level of cryptographic keys, activation data, critical security parameters, key management and other technical security measures regarding Fina RDC 2015 CA and for issuing Subscriber certificates.

Specific procedures and protection measures conducted in order to achieve the required security level are of internal nature and are not published.

6.1 Key pair generation and installation

6.1.1 Key pair generation

Fina carries out Fina RDC 2015 CA key pair generation using algorithms for key generation that are aligned with the standardisation document ETSI TS 119 312 [12].

6.1.1.1 Generation of Fina CA Key Pairs

Fina RDC 2015 CA key pair generation procedure is carried out in a formal key pair generation ceremony for subordinate Fina CAs. The ceremony is witnessed by authorised persons in Fina PKI.

The Fina RDC 2015 CA key pair generation ceremony is carried out according to the protocol for key generation in which the steps taken during the ceremony are documented. The key generation protocol is in compliance with the technical security measures according to standard HRN ETSI EN 319 411-1 [7] and the requirements of CA/Browser Forum BRG [19].

Cryptographic algorithms used for key generation, as well as the key length for Fina RDC 2015 CA are chosen in line with the standardisation document ETSI TS 119 312 [12], in order to be adequate during the whole time of CA certificate's validity.

Key pairs for Fina RDC 2015 CA are generated, under at least dual control of authorised persons with trusted roles in Fina PKI, in HSM module that meets the requirements referred to in Section 6.2.1 hereof.

Fina RDC 2015 CA is located in Fina PKI protected premises referred to in Section 5.1.1 hereof during and after the key pair generation ceremony, and access to Fina RDC 2015 CA is allowed only to Fina PKI authorised persons with trusted roles exercising at least dual control.

The Fina RDC 2015 CA key pair generation ceremony procedure is videotaped or the conducted procedure is witnessed by a Qualified Auditor.

The performed CA keys generation procedure is recorded with the accompanied audit logs.



Fina is in possession of the Qualified Auditor's report witnessing that the Fina RDC 2015 CA key pair generation procedure has been carried out in compliance with the protocol and the requirements for key generation.

6.1.1.2 Key Pair Generation for Subscriber Certificates

Only Fina or pertaining Custodian may generate Subscriber key pairs for SSL certificate level 2 (OVCP).

Generation of Subscriber key pair for SSL certificate level 3 (OVCP) is carried out only by a pertaining Custodian.

Insofar as the key pair generation for a SSL certificate level 2 (OVCP) is carried out by Fina, the generation is carried out in the cryptographic module in Fina PKI protected premises. The generation of Subscriber key pairs for SSL certificate level 2 (OVCP) is aligned with the standard HRN ETSI/EN 319 411-1 [7] and with the requirements of CA/Browser Forum BRG [19].

Insofar as key pair generation for a SSL certificate level 2 (OVCP) is carried out by a Custodian, the generation is carried out in a controlled environment at the location of the Subscriber. Private keys are protected in a software protected token in the manner described in Section 6.2.1 hereof.

The generation of Subscriber key pairs for SSL certificate level 3 (OVCP) is carried out by the Custodian in a controlled environment at the location of the Subscriber, in the HSM module that meets the requirements referred to in Section 6.2.1 hereof.

Fina shall reject a certificate issuance application if the submitted Subscriber public key does not meet the requirements listed in Sections 6.1.5. and 6.1.6 hereof.

6.1.2 Private key delivery to subscriber

If Fina generates the private key which will be connected to an SSL certificate level 2 (OVCP), in that case the private key and its pertaining certificate is delivered to the registered Custodian in the form of a protected PKCS#12 file. The protection of the PKCS#12 file is carried out based on activation data set by the Custodian before its delivery. The delivery of the PKCS#12 file is done online via a TLS channel through the use of a Fina CMS system, upon prior successful authentication of the Custodian. After the delivery of the PKCS#12 file to the Custodian, Fina destroys the pertaining private key and the PKCS#12 file.

In the event that Fina has knowledge that the private key connected to the SSL certificate level 2 (OVCP) has been delivered to an unauthorised person or Legal person not connected with the private key, Fina shall revoke all certificates containing the public key connected with this private key.

If the Custodian generates a private key in the HSM module or software module, it is deemed that the Subscriber is already in possession of a private key.



6.1.3 Public key delivery to certificate issuer

The Subscriber public key is delivered electronically using Fina CMS system which, upon successful authentication of the person authorised for generating Subscriber key pair, establishes TLS communication channel. The public key is delivered in PKCS#10 formated request which is signed by a generated Subscriber private key. Persons authorised for generating Subscriber key pair are given in Section 6.1.1 hereof.

If a Subscriber key pair is not generated by Fina, the certificate application process checks whether the Custodian possesses or controls his/her own private key connected to the public key, which is delivered for certificate creation, in a manner which certainly connects the Custodian’s identity and the pertaining public key which is delivered for certification. The public key is delivered in a PKCS#10 formated request using the Fina CMS system upon the establishment of TLS communication channel after successful authentication of the Custodian.

6.1.4 CA public key delivery to relying parties

The public keys Fina RDC 2015 CA are accessible to Relying Parties in Fina RDC 2015 CA certificates issued by Fina Root CA, and in this way integrity is secured and verification of the authenticity of the public keys of Fina CA RDC 2015 CA is enabled.

Verification of the authenticity of the Fina RDC 2015 CA public keys is ensured by:

• Publication of Fina Root CA certificate and certificates of Fina RDC 2015 CA on the website of Fina PKI repository referred to in Section 2.2 hereof, and by the delivery of a hash of Fina Root CA certificate through a trusted channel at the request,

• Publication of the certificates of Fina RDC 2015 CA on a national reliable list of Qualified Trust Service Providers (Trusted list), which is published on the website of the central state administration authority competent for economic affairs as the authority responsible for the reliable list of Qualified Trust Service Providers in the Republic of Croatia.

6.1.5 Key sizes

The key lengths in Fina PKI are as follows:

• Fina Root CA uses sha256WithRSA algorithm with 4096-bit long keys, • Fina RDC 2015 CA uses sha256WithRSA algorithm with 4096-bit long keys, • Fina OCSP service uses 2048-bit long RSA keys, • Subscribers use 2048-bit long RSA key pairs.

6.1.6 Public key parameters generation and quality checking

Fina RDC 2015 CA carries out key pair generation using generation parameters in compliance with the standardisation document ETSI TS 119 312 [12].



Compliance with the requirements for generation and verification of key quality parameters is ensured by using certified HSM modules or cryptographic modules, in accordance with the appropriate standards referred to in Section 6.2.1 hereof, and by strictly abiding by the requirements listed in the documentation of the those devices.

When generating key pairs, the Custodian carries out key pair generation in a manner which ensures parameter use in accordance with the ETSI TS 119 312 [12] standard. and CA/Browser Forum BRG [19]. Upon the receipt of a public key generated by the Custodian, Fina checks if the public key complies with the quality level prescribed by the aforementioned documents, and rejects the public key which does not comply with the quality requirements, and does not issue a certificate for that key.

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

The Fina RDC 2015 CA certificate has keyCertSign and CRLSign value set in the Key Usage extension. Fina RDC 2015 CA uses the pertaining key only for:

• signing subscriber certificates and certificates for LRA, • signing certificates for OCSP service response signature, • signing certificates for Qualified Time-Stamp, • signing corresponding CRLs.

Certificates from Table 1.1 and Section 1.1.2 hereof are intended for website authentication. The extension Key Usage of these certificates has been marked critical and it has the set values digitalSignature and keyEncipherment.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic module standards and controls

The Fina RDC 2015 CA private key is generated and protected by a HSM module that complies with the requirements of FIPS 140-2 [14] Level 3.

Fina OCSP service private keys are generated and protected by HSM modules meeting the requirements of FIPS 140-2 [14] Level 3.

Protection of a private key SSL certificates level 2 (OVCP) is carried out in a software protected token in the controlled environment at the Subscriber location. The Subscriber is in charge of the method of protecting private keys of SSL certificates level 2 (OVCP) at the Subscriber location.

Protection of SSL certificates level 3 (OVCP) private keys is carried out using a HSM module that complies with the requirements of standard FIPS 140-1 [13] or 140-2 [14] level 3 or higher, or the requirements of applicable equally valued security criteria, with implementation of additional physical and ICT protection measures at the Subscriber location.



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

The HSM modules protecting private keys of Fina RDC 2015 CA and OCSP services are located at the premises of the highest security level inside the Fina PKI protected premises. Physical access to such HSM modules is subject to dual and two-parameter control of authorised persons with Fina PKI trusted roles.

Fina RDC 2015 CA private signing key management is carried out under at least dual control by persons with trusted roles in Fina PKI. While managing private keys, Fina RDC 2015 CA persons with trusted roles use the corresponding control cards of the cryptographic module based on n of m principle.

6.2.3 Private key escrow

Fina RDC 2015 CA private key escrow is not allowed.

Subscriber private key escrow associated with certificates is not allowed.

6.2.4 Private key backup

Fina RDC 2015 CA private key backup is carried out under dual control by authorised persons with trusted roles in Fina PKI on the premises of the highest security level within the Fina PKI protected premises. Fina RDC 2015 CA private key is kept outside of the HSM module exclusively in encrypted form and in that form it is backed-up and stored in a secure location of the highest security level within the Fina PKI protected premises on separate locations.

Only authorised persons with Fina PKI trusted roles and implementation of dual control have physical access to security copies of Fina RDC 2015 CA private keys.

Fina never carries out security backup of Subscriber private keys connected to certificates.

The Subscriber is responsible for the protection of the private key copies for SSL Certificate Level 2 (OVCP) and is also be responsible in the case of their unauthorised use in the same manner as for the originals, pursuant to Section 9.6.3 hereof.

6.2.5 Private key archival

The private key Fina RDC 2015 CA is not allowed to be archived, and is destroyed in accordance with Section 6.2.10 hereof.

The Subscribers' private keys are not allowed to be archived.

6.2.6 Private key transfer into or from a cryptographic module

While out of HSM, the private key is protected by encryption. Private key encryption is carried out by strictly abiding by the requirements given in the HSM certification documents and this ensures the same security level of private key protection, as well as when the key is in the HSM module.



The transfer of private key Fina RDC 2015 from HSM module is authorised by persons with trusted roles in Fina PKI, with dual control, within CA area of Fina PKI protected premises.

During the transfer of private keys from one HSM into another HSM, the private key is allowed to be transferred only to an HSM of equal or higher level of security in relation to the HSM from which the private key is being transferred.

The transfer of private keys for the SSL certificate level 2 (OVCP) into another private key security container is carried out by the Custodian, in a manner that the private key is only transferred into a cryptographic module of equal or higher level of security in relation to the cryptographic module from which the private key is being transferred. Before transfer, the private key is encrypted so that it would be adequately protected during the transfer.

6.2.7 Private key storage on cryptographic module

Fina RDC 2015 CA private key is protected with a HSM module and may be used only if duly activated.

SSL certificate level 3 (OVCP) private key is protected with a HSM module and may be used only if duly activated.

There are no limitations regarding the format in which private keys are stored in HSM modules.

6.2.8 Method of activating private key

Initiation of Fina RDC 2015 CA service for the creation of certificates and activation of Fina RDC 2015 CA private key on hardware cryptographic module is carried out under dual control by Fina RDC 2015 CA authorised persons using control cards of the cryptographic module.

Once activated, the private key remains activated with no time limit.

Certificate private keys activation is conducted by the pertaining Custodian through the use of his/her PIN or corresponding activation data. Private key activation is carried out in a secure manner.

Only the Custodian knows the PIN and the corresponding activation data for the activation of his/her private key. The Custodian activates the private key in a manner in which the PIN or the corresponding activation data remain permanent.

6.2.9 Method of deactivating private key

The deactivation of a Fina RDC 2015 CA private key is carried out according to procedures and upon compliance with requirements set in the certification document of the HSM module used, with dual control by authorised persons with Fina PKI trusted roles.



Fina RDC 2015 CA private key deactivation is carried out when there is an immediate request for temporary termination of system activities, in cases of private key validity period expiration and in cases of pertaining certificate revocation. Fina RDC 2015 CA private key is deactivated by:

• stopping the CA server process, • shutting HSM down, • shutting HSM-linked server down.

The Custodian is responsible for certificate private keys stipulated deactivation and use.

Certificate private keys protected by a HSM module are deactivated by cutting off power to the devices or through an command from the Subscriber application for the deactivation of a device.

A deactivated certificate private key may be reused only after the reactivation of the corresponding activation data.

6.2.10 Method of destroying private key

The procedure for destruction of a Fina RDC 2015 CA private key is carried out after the expiry of the private key validity period because it has been compromised or because of suspicion that a private key has been compromised, or due to cessation of its use, and is carried out by authorised persons with trusted roles in Fina PKI with at least dual control. The procedure for destroying Fina RDC 2015 CA private key permanently disables all the backups of that private key and they are no longer useful.

When Fina CA HSM's are decommissioned or prior to HSM transfer to another location, the Fina CA private signing key located inside the HSM is destroyed according to the HSM‘s manufacturer instructions. Destroying a private key in HSM is performed before the HSM leaves the Fina PKI protected area.

Fina RDC 2015 CA private key destruction is conducted pursuant to Fina′s internal procedures in the presence of persons with trusted roles in Fina PKI.

It is recommended that the Subscriber destroy every certificate private key that has been put out of use permanently.

The Custodian destroys certificate private keys.

The Custodian is responsible for the destruction of certificate private keys.

The destruction of certificate private keys stored in a HSM module is carried out by a Custodian in a way that ensures that, once destroyed, the private key may not be recovered or used.



6.2.11 Cryptographic Module Rating

The rating of HSM modules and other cryptographic modules is carried out according to standards for cryptographic modules listed in Section 6.2.1 hereof.

6.3 Other aspects of key pair management

6.3.1 Public key archival

Fina RDC 2015 CA and Subscriber certificate public keys are archived in order to provide evidence for certificates in judicial, administrative and other procedures.

Fina RDC 2015 CA public keys are an integral part of corresponding CA certificates which are archived pursuant to Sections 5.5.3. and 5.5.4 hereof, and are stored in the archive for the time period set in Section 5.5.2 hereof.

Subscriber public keys are an integral part of corresponding certificates which are archived pursuant to Sections 5.5.3. and 5.5.4 hereof, and are stored in the archive for the time period set in Section 5.5.2 hereof.

6.3.2 Certificate operational periods and key pair usage periods

Certificate validity period according to types is defined in Table 6.1.

Certificate Term

Fina RDC 2015 CA Certificate 10 years

Fina OCSP service responder signing certificates 1 year

SSL Certificate Level 2 (OVCP) 2 years

SSL Certificate Level 3 (OVCP) 1 year

Table 6.1. Certificate Validity Period

The validity period of Fina RDC 2015 CA certificates must not be outside of the validity period of Fina Root CA certificates.

The private key period of validity is equal to the period of validity of the pertaining certificate. Certificates and pertaining keys are not allowed be used after the expiry of the validity period of certificates nor after certificate revocation.



6.4 Activation data

6.4.1 Activation data generation and installation

Activation data connected to Fina RDC 2015 CA private keys are generated and installed during the carrying out of a formal private key pair generation ceremony for subordinated Fina CAs. Activation data are installed on pertaining control cards of the cryptographic module used for Fina RDC 2015 CA private key activation based on n out of m principle.

If certificate private keys are generated by Fina, then prior to that, Fina also generates the pertaining authentication data used by the Custodian to log in to Fina CMS. Activation data protecting the private key in PKCS#12 data are generated and entered by the authenticated Custodian using Fina CMS and CMS and TLS communication channel.

Activation data for the SSL certificate level 3 (OVCP) are generated by the Custodian.

If the Custodian generates the activation data, the Subscriber is responsible for the security and compliance with the stipulated quality requirements of the activation data.

6.4.2 Activation data protection

The activation data connected with the Fina RDC 2015 CA private key are kept in a secure manner.

Fina RDC 2015 CA private keys activation data which are stored on pertaining control cards of the cryptographic module are protected by corresponding passwords which are generated at Fina PKI protected premises. Control cards of the cryptographic module are assigned to Fina PKI authorised persons with trusted roles. Control cards of the cryptographic module and corresponding passwords are stored separately in safe storage of each Fina PKI protected premises.

If certificate private keys are generated by Fina, then Fina delivers the authentication data to the Custodian so he or she may log in to Fina CMS using two separate channels.

Custodians are in charge of protection and keeping of activation data of corresponding private keys.

Activation data should not be stored together with the HSM or secure cryptographic device which they refer to.

The Subscriber is responsible for the protection of private key activation data connected to certificates.

6.4.3 Other aspects of activation data

Activation data for certificate private keys may be periodically modified to minimise the possibility of their disclosure.

There are no further requirements regarding the life-cycle of activation data of certificates.



Additional rules about the terms and conditions, and life cycle of a subject's activation data are specified in the Subscriber agreement.

6.5 Computer security controls

6.5.1 Specific computer security technical requirements

HSM that protects Fina Root CA private key is isolated from all other regular operations by being on dedicated hardware and is intended solely for the protection of the Fina Root CA private key. A computer that performs the function of Fina Root CA is in the same manner isolated from all other regular operations. The Fina Root CA with its HSM is disconnected from the computer network (offline) for the entire time and is in regular situation always shut down. Only persons with confidential roles in Fina PKI have the authorization to start up the Fina Root CA with the associated HSM. Only authorized persons with confidential roles in Fina PKI have access to the Fina Root CA private key according to section 6.2.2. of CP/CPSROOT [21] document.

Only authorised persons after authentication have access to the IT system and applications in Fina PKI. Access control to Fina RDC 2015 CA server operation system allows access only to authorised personnel with trusted roles within Fina PKI.

Fina separates duties and responsibilities for trusted roles of the Fina PKI personnel, pursuant to Section 5.2.4 hereof.

Fina manages the accounts of authorized persons with confidential roles in the Fine PKI in accordance with internal documentation. Managing user accounts includes timely change of user rights, disabling access and termination of user account.

Identification and identity verification for each Fina PKI trusted role is carried out using the appropriate means for authentication pursuant to Section 5.2.3 hereof.

Two-factor authentication is necessary for all accounts that may directly initiate certificate issuance.

Modifications to and publication of the revocation status of certificates is carried out with two-factor authentication and mandatory control of access.

The Fina PKI system carries out continuous monitoring and has a detection system for the purpose of detecting, recording and timely reaction to attempts at unauthorised access to system resources.

A system for protection against malware is implemented and unauthorised software use is not allowed. CA software test is conducted in order to check its authenticity and integrity.

Data storage devices that contain or that contained the confidential data are securely deleted using the tools prescribed in the internal Fina documentation prior to re-use outside of the PKI to prevent unauthorized access to the data contained therein.



Communication between Fina CMS and Subscriber's client application is carried out through the secure channel.

6.5.2 Computer security rating

With aim of security and quality of the provided trust services, Fina established a system for information security management pursuant to ISO/IEC 27001 [4] standard. Compliance is verified by a certificate issued by an independent certification authority.

6.6 Life cycle technical controls

6.6.1 System development controls

When procuring development software from an external subcontractor, Fina ensures the system development security principles in an agreement with the supplier.

The analysis of security requirements is carried out in the design and specification phase of any development project of Fina PKI systems, to ensure that security has been incorporated in the information technology of Fina PKI systems.

Software used to provide non-qualified certificate issuance services originates from a reliable source. New versions of software are tested in a test environment. Implementation of software in production is carried out in accordance with documented procedures of change management.

The plan for Fina PKI system configuration management contains a clear overview of the current situation, the list of the documentation generated as a part of information system creation, measures for quality assurance, vulnerability assessment, software design, system test and definitions of control mechanisms.

6.6.2 Security management controls

The system for certification automatically carries out periodical integrity verification of database, which verifies the data consistency in the database. Automatic periodical verification of the integrity of audit log system for certification is also carried out.

During shipment from supplier, HSMs for Fina CAs are protected with measures against breaches and unauthorized modifications provided by the manufacturer. When delivered, HSMs are checked against breaches and their integrity is checked. Transfer of HSM by Fina is regulated by a special internal procedure.

During HSM initiation, automatic verification of their integrity is carried out.

Fina manages applying of software patches through a change management system. Timely installation of available software patches is made. Before installing a patch, checks are made whether patching is causing instability or introduces vulnerabilities in system operation.



Reasons why a particular patch is not applied are documented through a change management system.

During the installation of software and its patches in Fina PKI, measures for authentication and integrity verification of the software are taken.

Authorised personnel in Fina control and supervise the Fina PKI system settings.

Fina verifies all parts of the certification system in the Fina PKI production hierarchy, which is based on Fina Root CA, with respect to security, reliability and quality of operation, all in accordance with laws in force referred to in Section 9.14 hereof.

In the event of a breach in certification system security or loss of its integrity which may have a significant impact on the provision of trust services or on the protection of personal data, Fina shall within 24 hours notify the central state administration authority competent for economic affairs about this, as the authority competent for supervision of Trust Service Providers, and, if necessary, other competent authorities. In the event that the loss of integrity may have a negative impact on the Subscribers of Fina trust services, Fina shall immediately notify all Natural persons - citizens and Legal person that may be impacted by the security breach.

6.6.3 Life cycle security controls

Fina carries out change management in Fina PKI to ensure that changes occur for justified reasons, and in a controlled and formalised way.

The integrity of the certification and information systems is protected by anti-virus protection and the use of authorised software.

Monitoring of available certification system capacities is carried out, and the compliance of existing capacities for future needs of the system are assessed to plan their expansion in a timely manner.

6.7 Network security controls

The computing network security of Fina PKI system is based on the concept of network separation by different level network zones. Network zones are separated by firewalls allowing only necessary network traffic. Equal security measures are applied to all systems located within the same network zone.

Network segment with the working stations for Fina RDC 2015 CA administration is separated by a firewall from the rest of the network segments and computers which are present in those network segments.

Equipment for computer network protection keeps record of traffic flow and attempts to access Fina RDC 2015 CA services and LDAP public directory service. The recorded information is defined in Section 5.4.1 hereof. Only authorised Fina PKI personnel have administration authorisations for the set-up and management of the equipment for the



protection of computer network. Remote adjustment of computer network protection equipment is not allowed.

Unnecessary communication, accounts, ports, protocols and services are explicitly prohibited or deactivated.

The Fina PKI internal computer network is protected against unauthorised access, including access by Subscribers and third parties.

All systems critical for providing Trust Services are located in the Fina PKI protected premises and are divided in several secured network zones.

Network access to critical systems in the Fina PKI protected premises is disabled from outside of the Fina PKI protected premises.

CA systems are specially security adjusted and hardened.

The network component of Fina PKI systems is stored in a physically and logically secure environment and the compliance of its configurations is periodically checked.

6.8 Time-stamping

Time-Stamps are not used within the scope of the certification services referred to in this CPSWSA-eIDAS.

Time in the Fina certification system is synchronised with UTC time. Fina PKI audit logs contain accurate data regarding the date and time they originated, with a deviation of less than +/- 1 second.



7 CERTIFICATE, CRL, AND OCSP PROFILES

7.1 Certificate profile

This Chapter describes the certificate profile, Certificate Revocation List (CRL) and OCSP service responses issued by Fina, as the certification provider, through Fina RDC 2015 CA, pursuant to this CPSWSA-eIDAS document.

Certificate profiles within the scope of this CPSWSA-eIDAS document issued by Fina RDC 2015 CA are in compliance with ETSI EN 319 411-1 [7] and ETSI EN 319 412 [8], [9] and [10] standards.

Subordinate Fina RDC 2015 CA issue certificates according to the profiles determined herein. Depending on the certificate purpose, rules by which the certificate was issued, security level and the manner of storing the pertaining private keys, each certificate type has a unique Fina CP OID defined, and besides that OID, it also contains the corresponding ETSI OID of the Certificate Policy.

7.1.1 Version number(s)

Certificates are compliant with version 3 according to the X.509 specification.

7.1.2 Certificate extensions

The document with a description of the certificate profile is available on the website of Fina PKI repository referred to in Section 2.2 hereof.

7.1.3 Algorithm object identifiers

Algorithms with pertaining OID identifiers for all certificates issued by subordinate Fina RDC 2015 CA are shown in Table 7.1.

Algorithm OID

sha256WithRSAEncryption 1.2.840.113549.1.1.11

rsaEncryption 1.2.840.113549.1.1.1

Table 7.1. Algorithms with Pertaining OID Identifiers

7.1.4 Name forms

Subordinate Fina RDC 2015 CA name forms have been described in Section 1.3.2 hereof.

Name forms for certificates issued by subordinate Fina RDC 2015 CA are described in Sections 3.1.1. and 3.1.4 hereof.



7.1.5 Name constraints

The extension Name Constraints is not used.

7.1.6 Certificate policy object identifier

Certificate Policies extension contains the corresponding Fina and ETSI OIDs. In Tables 1.1 of the Section 1.1.2 hereof, a list is given of certificate types and the pertaining Fina and ETSI OIDs in Certificate Policy extension.

7.1.7 Usage of Policy Constraints extension

The extension Policy Constraints is not used.

7.1.8 Policy qualifiers syntax and semantics

Policy qualifiers in the extension Certificate Policies contain two pointers in the URI format that contain the website address of this CPSWSA-eIDAS document in Croatian and English.

7.1.9 Processing Semantics for the critical Certificate Policies extension

No stipulations.

7.2 CRL profile

CRL profile issued by subordinate Fina RDC 2015 CA is in line with IETF RFC 5280 [16] recommendation.


CRL is compliant to version 2 according to the X.509 specification.

7.2.2 CRL and CRL entry extensions

CRL extensions used in CRL lists and extensions used in entry elements of CRLs that are issued by Fina RDC 2015 CA are defined in Table 7.2.

Extensions Critical Value

crlExtensions

cRLNumber NO Monotonically increasing sequence number for CRL in the form of 20 octets.

AuthorityKeyIdentifier NO 160 bits SHA-1 hash

crlEntryExtensions

reasonCode NO Reason code of the certificate revocation

Table 7.2. Extensions of CRL List and Entry Elements of CRL Lists issued by Fina RDC 2015 CA



7.3 OCSP profile

The Fina OCSP service responder OCSP profile is in accordance with the IETF RFC 6960 recommendation [17].


The Fina OCSP service responder OCSP profile is in accordance with version 1 according to IETF RFC 6960 [17].

7.3.2 OCSP extensions

Fina OCSP service response extensions are given in Table 7.3.

Extensions Critical Value

Nonce NO Nonce value from certificate status request.

Extended Revoked Definition NO Reason code for certificate revocation

Table 7.3. Fina OCSP service response extensions



8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS

Supervision over the work of Fina as a Trust Service Provider is regulated by Regulation (EU) No. 910/2014 [1] and Act Implementing Regulation (EU) no. 910/2014 [2] and is carried out by the central state administration authority competent for economic affairs.

Supervision over the work of Trust Service Providers in the field of collection, use and protection of personal data may also be carried out by government and other bodies laid down by law and other rules and regulations governing personal data protection.

Compliance audit is carried out with the aim of confirming that Fina as a Trust Service Provider and provider of certificate issuance services, meets the requirements stipulated in the Regulation (EU) No. 910/2014 [1], Act Implementing Regulation (EU) no. 910/2014 [2] and the standard HRN ETSI/EN 319 411-1 [7].

Fina have a quality management system in line with ISO 9001 standard implemented, which has been in the certification cycle for years, which means that it meets the requirements of the standard, it has a documented system, defined authorisations, responsibilities and described processes.

Also, Fina have a continuously supervised, certified and, based on business needs, enhanced own system of information security in line with ISO/IEC 27001 [4] standard established.

8.1 Frequency or circumstances of assessment

Compliance audits of Fina PKI operations are external compliance audits and internal compliance audits.

8.1.1 External Compliance Audit

External compliance audit is carried out at least every 12 months, in accordance with the requirements of standards HRN ETSI/EN 319 411-1 [7] and ETSI EN 319 403 [11].

8.1.2 Internal Compliance Audit

Internal compliance audit is carried out prior to the commencement of providing new services, periodically at least each 12 months, and after significant changes to Fina PKI operations.

Compliance audit of certificates with this CPSWSA-eIDAS and Certificate Policy [22], as well as in accordance with the requirements referred to in CA/Browser Forum, BRG [19] is carried out quarterly on a random sample of at least 3 % of certificates issued after the previous audit.

Internal compliance audit checks the compliance of the system with the ETSI EN 319 411-1 [7] standard and requirements referred to in CA/Browser Forum, BRG [19].



8.2 Identity/qualifications of assessors

External compliance audits are conducted by a conformity assessment body. The competence of the conformity assessment body and the qualification of the associated assessors is ensured by the accreditation of the conformity assessment body according to the standard ETSI EN 319 403 [11].

Internal compliance audits are conducted by internal compliance assessors who together have knowledge and understanding:

• about the provisions of the standard HRN ETSI/EN 319 411-1 [7], • about PKI areas and information security area, • about legislation in the area of providing trust services.

Internal compliance auditors carry out internal compliance audits with the help of employees which have been assigned the trusted role of System Auditor.

8.3 Assessor's relationship to assessed entity

The conformity assessment body and associated assessors are independent of Fina and Fina's assessment system.

Internal compliance assessors do not assess compliance within their own scope of responsibilities.

8.4 Topics covered by assessment

The subjects of compliance assessment include the following areas of trust services provision:

• integrity and accuracy of documentation, • implementation of requirements for trust services, • organisational processes and procedures, • technical processes and procedures, • implementing information security measures, • reliable systems, • physical security at subject locations.

The description of compliance assessment topics is defined in the compliance assessment plan. Fina shall enable the compliance assessor to access all Fina PKI system premises, access to reports of all internal and external compliance audits and to other reports and records within the scope of trust services. Fina shall also enable the compliance assessor to access records and agreements relating to thirds parties, to internal, external and management reports etc. within the scope of trust services.



8.5 Actions taken as a result of deficiency Depending on the significance of the detected deficiency, the external deficiency assessor may indicate in the report which deficiency must be eliminated by Fina.

In case of a significant deficiency, Fina shall form a plan of the significant deficiency elimination as soon as possible, and it shall eliminate the deficiency as soon as possible after consulting with the external assessor.

In the event that a significant deficiency has been detected during the provision of trust services and it has not been eliminated within a short notice, Fina shall take the necessary steps to eliminate the deficiency, and, if applicable, within the period set by the supervisory body.

In consultation with the external assessor, Fina shall eliminate smaller deficiencies until the next compliance audit.

External assessor may suggest and advise a modification which affects trust services in order to enhance efficiency or improve trust services. In that case, Fina reserves the right to accept the suggestion.

During certificate issuance termination due to the identified significant inconsistency, Fina shall issue only those certificates which are indicated as certificates for internal and testing purposes and it shall ensure that those certificates are not available to any other Subscriber.

8.6 Communication of results The results of internal compliance audits are of a confidential nature and Fina does not make these public.

All documents about the internal compliance audit are available at request to external assessors carrying out compliance audit in the Fina PKI system.

Fina publishes the results of external compliance audits on the website of the repository referred to in Section 2.2 hereof within three months upon the end of external compliance audit. Non-compliance established during compliance audits is not disclosed because they may contain confidential information.



9 OTHER BUSINESS AND LEGAL MATTERS

9.1 Fees

Fina and the External RA, in accordance with the requirements referred to in the concluded agreement, shall notify Subscribers or Relying Parties about all services to be charged. Unless otherwise provided for in a separate agreement, services are charged in accordance with Fina's price list. The price list of all charged services is published on the website of the repository referred to in Section 2.2 hereof.

Fina reserves the right to change the price list. Price list changes are published on the website of the repository referred to in Section 2.2 hereof.

9.1.1 Certificate issuance or renewal fees

In accordance with the published price list, Fina charges fees for the services of issuance and renewal of certificates.

9.1.2 Certificate access fees

Fina does not charge certificate access fees.

9.1.3 Revocation or status information access fees

In accordance with the published price list, Fina charges fees for certificate revocation services.

Fina does not charge the service of providing information about the revocation status of certificates, which it provides as part of OCSP service or publication of CRL.

9.1.4 Fees for other services

Fina may also decide, in accordance with the provisions of the agreement, to determine and charge appropriate fees for other services, such as the registration of Subscriber, modification of data in certificates, delivery of certificates and equipment at the location of the Subscriber, etc.

No fees are charged for accessing this CPSWSA-eIDAS document or the Certificate Policy.

9.1.5 Refund policy

Fina shall refund fees to Subscribers in the event of incorrect payment or overpayment.



9.2 Financial responsibility

Fina, as a Trust Service Provider, possess financial stability and have at its disposal sufficient financial resources to ensure unhindered provision of certification services in accordance with this CPSWSA-eIDAS document.

9.2.1 Insurance coverage

Fina, as a Trust Service Provider, have insurance against damage liability risks occurring while carrying out certification services.

Fina additionally insures property by means of an insurance policy covering insurance against the risk of fire, severe weather, floods, explosions, vehicle impact, aircraft fall or impact, demonstrations, insurance of equipment, machinery, electronic and communication devices, installations etc.

9.2.2 Other assets

No stipulations.

9.2.3 Insurance or warranty coverage for end-entities

See Section 9.2.1.

9.3 Confidentiality of Business information

9.3.1 Scope of confidential information

Confidential business information include all information in relation to certification service establishment and provision, regardless of their form, exchanged by the participants through any means of communication and labelled as confidential, or as being of a specific type or having a specific level of secrecy, by the participants, or which are confidential by their nature, because an unauthorised disclosure thereof might cause damage to the participant.

9.3.2 Information not within the scope of confidential information

Data integrated into the content of the certificate, data about certificate status, and data and documents published in the Fina PKI repository are not deemed confidential business information.

9.3.3 Responsibility to protect confidential information

Each participant shall protect the confidential business information referred to in Section 9.3.1 hereof that they somehow became aware of, in accordance with laws regulating the information protection considering information type and information secrecy type and level. Otherwise, it shall be held liable for the damage incurred.



9.4 Privacy of personal information

Upon concluding the Subscriber Agreement, the Signatories agree on publishing the certificates in the public directory, on the fact that Fina uses and processes their data collected in the process of registration in accordance with the legislation in force, and that Fina is authorised to store the data for at least 10 years from the date of expiry of the certificate to which it refers.

9.4.1 Privacy plan

Fina carries out technical, personnel and organisational protection measures of personal data in accordance with the Act on Personal Data Protection [3] for the purpose of protection of personal privacy and protection of data against possible misuse, and the preservation of the accuracy, completeness and relevance of personal data.

Measures for personal data protection apply during the exchange of personal data of Subscribers between the RA Network and certification system, and during the keeping and archiving of Subscriber personal data until their extraction from the archive and destruction.

9.4.2 Information treated as private

During and after the Subscriber registration procedure, Fina is authorised to collect personal data required for duly Subscriber identification and other data required for duly certification service provision. Personal data collected by Fina which are not contained in the certificate are confidential personal data duly protected by Fina.

9.4.3 Information not deemed private

Personal data collected by Fina during and after the Subscriber registration procedure and which are integrated in the certificate is not deemed confidential personal data due to their availability to all interested parties.

9.4.4 Responsibility to protect private information

Fina is responsible for the protection of personal data collected for the purpose of providing certification services.

9.4.5 Notice and consent to use private information

Aside from the needs for the purpose of complying with statutory and contractual obligations under the Subscriber Agreement, Fina is authorised to use and publish personal data only upon the written consent of the Subscriber.

9.4.6 Disclosure pursuant to judicial or administrative process

Fina does not make available the data referred to in Sections 9.3.1. and 9.4.2 hereof, except in cases stipulated by law or when required in writing by the competent court, administrative or other governmental body.



9.4.7 Other information disclosure circumstances

No stipulations.

9.5 Intellectual property rights

Fina has intellectual property rights over this CPSWSA-eIDAS document, as well as other Fina documentation published on the website of the repository referred to in Section 2.2 hereof.

Fina does not exercise intellectual property rights over the software used in Fina PKI which is owned by third parties.

The owner of a private and public key is the Subscriber and only he is authorised to use a private key, regardless of whether the key pair is generated by the Custodian or whether6 Fina generates it as a Trust Service Provider, and regardless of the manner in which the private key is protected.

Fina, as the provider of certification services, is the owner of certificates it issues.

9.6 Representations and warranties

9.6.1 CA representations and warranties

Fina is responsible for the compliance of this CPSWSA-eIDAS with the Certificate Policy [22] and the legislation and for implementing the provisions stipulated herein, the terms and conditions of the certification services and in accordance with the obligations in the Subscriber Agreements concluded with the Subscriber.

Fina publishes on the website of the repository referred to in Section 2.2 hereof, the terms and conditions of certification services, this CPSWSA-eIDAS document, the Certificate Policy [22] and all notifications and information concerning changes in operation that may affect Fina PKI participants in any way.

Fina, as the Trust Service Provider, is responsible for damage incurred while providing services caused by the Legal persons with whom Fina has subcontracted part of the certification services. This responsibility between Fina and the Legal person is regulated by means of a separate agreement.

Fina is responsible for:

• correct verification of identity, data and authorisation of the applicant with the aim of collecting data for certificate issuance,

• issuance of certificates in a secure manner in order to preserve their authenticity and accuracy,

• compliance with its obligations.



In accordance with representations and warranties, Fina:

• verifies the applicant's control and exclusive right over the domain name or IP address contained in the certificate,

• before issuing certificates, verifies whether the Subscriber has approved the issuance of certificates and that the applicant has been authorised by the Subscriber to submit a certificate issuance application,

• has established procedures with which it verifies the accuracy of all data contained in a certificate before their issuance,

• has established procedures with which it secures a minimum possibility of misapprehension of data contained in a certificate,

• has established procedures for authentication of applicants and procedures for certificate issuance,

• concludes a Subscriber agreement in cases when a CA and Subscriber are not connected or are the same entity,

• in cases when Fina RDC 2015 CA issues a certificate for the needs of Fina, then Fina as the applicant is acquainted with certification terms and conditions,

• issues a certificate of the profile which is in accordance with Section 7.1 hereof, and according to the certificate type given in the certification application,

• if it generates Subscriber key pairs, generates them in a secure manner ensuring private key confidentiality, in accordance with this CPSWSA-eIDAS,

• ensures verification that the Subscriber is in possession of a private key whose pertaining public key is delivered for certification,

• ensures that the issued certificate is available in accordance with Section 4.4.2 hereof,

• on the basis of an authenticated and authorised application, after carrying out the stipulated procedure, revokes a certificate for the reasons listed in Section 4.9.1 hereof,

• provides updated information about the revocation status of certificate, • ensures that the repository is accessible to the public according to the principle 24x7

with current revocation status of all certificates whose validity period has expired, • upon providing certification services, applies the provisions of valid regulations

referred to in Section 9.14 hereof, • carries out the required security measures for protection of premises and equipment

of the certification system, • applies organisational and technical protection measures for keys and certificates in

accordance with this CPSWSA-eIDAS, • in accordance with the business continuity plan, ensures the unhindered work and

maximum availability of certification services, • monitors the availability of capacities, plans maintenance and further development of

certification systems in accordance with future needs, standard requirements and development of technology,

• protects the data deemed confidential according to Sections 9.3 and 9.4 hereof and use them exclusively for certification purposes within the scope of this CPSWSA-eIDAS,



• ensures that internal and external verification of compliance of Fina as the provider of

trust services are conducted in accordance with Section 8.1 hereof.

In the event of a disruption in operations, Fina shall act in accordance with Section 5.8 hereof.

Limitations to Fina's responsibility as a certification services provider are described in Section 9.8 hereof.

9.6.2 RA representations and warranties

RA Network representations and warranties are as follows:

• carrying out the registration and identification procedures for Natural persons - citizens and Legal persons in the manner stipulated hereof,

• forwarding complete, accurate and verified data about Subjects to Fina RDC 2015 CA for further processing,

• retention, archiving and protection of data for at least 10 years from the date of expiry of the certificate to which it refers,

• insuring the archived Subscriber data against loss or breach of confidentiality, integrity and accessibility, as stipulated herein,

• notifying applicants for certificate issuance about the published and accessible terms and conditions of providing certification services, Certification Policy [22] and this CPSWSA-eIDAS.

9.6.3 Subscriber representations and warranties

Before the initial certificate issuance, the Subscribers concludes an Subscriber agreement with Fina with which they accept the Certification Policy, this CPSWSA-eIDAS and the certification services terms and conditions.

For each certificate issuance, a certificate application is submitted.

A Subscriber, as a Legal person, is responsible for the accuracy, integrity and correctness of data submitted in the registration procedure and submission of the certificate application, and subsequently upon Fina's request, the connected certificate issuance.

The Subscriber is required to:

• in the registration process, present itself in the manner stipulated in Chapter 3. and in Section 4.1.2.2. hereof,

• carefully use and keep private keys and activation data in accordance with this CPSWSA-eIDAS,

• undertake appropriate protection measures for private keys and activation data against unauthorised access and use in accordance with Chapter 6 hereof,

• review and verify the accuracy of the content of the issued certificate before its acceptance,



• in the shortest possible period, request revocation of a certificate and terminate use

of the corresponding private key in the event of suspicion or actual incorrect use or compromise of a private key, and if any of the information contained in the certificate is incorrect in accordance with Section 4.9. of this CPSWSA-eIDAS,

• if a certificate has been revoked for the reason that a private key has become compromised, in the shortest possible period terminate any use of the private key connected with the public key in the Certificate,

• follow Fina's instructions related to the compromised key or incorrect use of certificates,

• use the certificate and the pertaining private key only on servers accessible through FQDN or IP addresses listed in the Subject Alternative Name extension certificate, and in accordance with legal and other provisions of the Republic of Croatia, and in accordance with the provisions of Section 1.4.1. and 1.4.2 hereof, the agreement and service provisions terms and conditions,

• use the certificate and corresponding private key in accordance with the provisions of Section 4.5.1 hereof,

• act in accordance with all other provisions of this CPSWSA-eIDAS that refer to Subscriber obligations.

The obligations and responsibilities of the Subscriber related to the use of private keys and certificates are described in Section 4.5.1 hereof.

The Subscriber, as a Legal person, by concluding a Subscriber Agreement with Fina accepts that Fina as a Trust Service Provider has the right to immediately revoke the certificate in case the Subscriber breaches the terms and conditions of the Agreement or the terms and conditions of the certification services, or in the event that Fina finds out that the certificate is used so as to allow for criminal activities, such as phishing attacks, fraudulent actions or malware distribution.

In the event of changes to contact data, the Subscriber is required to forward the changes to Fina at the contact information listed in Section 9.11 hereof.

The Subscriber is responsible for irregularities resulting from non-fulfilment of obligations determined in the above provisions referred to in this Section.

A Subscriber who does not act in accordance with the undertaken obligations may have their certificate revoked and shall lose all rights ensuing from the Subscriber agreement.

9.6.4 Relying party representations and warranties

A Relying Party is required make an autonomous and conscious decision on reasonable certificate reliance.

Reasonable reliance is deemed a decision by the Relying Party to rely on a certificate if at the time of reliance the Relying Party:

• undertaken the necessary precautionary measures and used the certificate for the purposes stipulated herein, that is, under circumstances in which reliance is



reasonable and in good faith, and under circumstances known or that should have been known to the Relying Party prior to relying on a certificate,

• used the application solution and IT environment on which it can rely, • checked the certificate validity period, • checked the certificate revocation, which the Relying Party confirms by carrying out

verification of the certificate status via the OCSP service or on the basis of the last issued CRL, as stipulated herein,

• checked if the private key used for authentication corresponds to the public key in the certificate within the certificate validity period,

The use of the public key and certificate by a Relying Party is described in Section 4.5.2. while the requirements for checking the revocation status of the certificate are set out in Section 4.9.6. hereof.

The Relying Party who has not abided by the regulations and this CPSWSA-eIDAS document, and has not acted in accordance with the obligations and responsibilities referred to in this Section alone bears the risks for reliance on such a certificate.

A Relying Party bears all the certificate reliance risks if it is aware of or has a reason to believe that facts exist that may cause personal or business damage due to reliance on the certificate.

9.6.5 Representations and warranties of other participants

No stipulations.

9.7 Disclaimer of warranties

Fina is not liable for damage, including indirect damage in the event of an accident, damage in the event of disaster with consequences or for any loss of profit, loss of data or other indirect damage arising out of certification services.

Fina is not liable for damage:

• suffered in the period from certificate revocation to the issuance of a new CRL, • incurred due to unauthorised use of Subscriber keys and certificates, • incurred as a result of the use of a certificate not permitted herein, • caused by fraudulent or negligent use of the certificate, CRL or OCSP service, • incurred as a result of a malfunction or error in the Subject's and the Relying Party's

software and hardware.

Fina is not liable for damage, including indirect damage, damage due to accident, damage in the event of disaster consequences or any loss of profit, loss of data or other indirect damage occurring as a result of providing false data and fraudulent presentation of a Subscriber during the process of identification and authentication if the authentication has



been carried out by a RA Network office in accordance with the requirement of this CPSWSA-eIDAS document and CPSNQC-eIDAS document [23].

9.8 Limitations of liability

Fina's total financial liability for non-qualified certificates issued according to this CPSWSA-eIDAS and CPSNQC-eIDAS [23] and transactions carried out in reliance on certificates issued in such a way amounts to a maximum of HRK 1,500,000.

Unless provided for in a separate agreement or determined otherwise, Fina's maximum financial liability towards a Subscriber and Relying Party, showing reasonable reliance in a certificate, is limited in accordance to the recommended financial limits shown in Table 1.5. Fina's maximum financial liability for non-qualified certificates is presented in Table 9.1.

Certificate category Fina's maximum financial liability

By category By transaction Total

Certificates of medium level of security - SSL certificate level 2 (OVCP) up to HRK 600,000 up to HRK 80,000

HRK 1,500,000

Certificates of high level of security - SSL certificate level 3 (OVCP) up to HRK 800,000 up to HRK 400,000

Table 9.1. Fina's maximum financial liability

9.9 Indemnities

Each participant is liable to the damaged party for damages caused by failing to comply with the provisions of this CPSWSA-eIDAS document, Certificate Policy and the relevant regulations in force.

Regardless of the disclaimers and limitations on liability towards Subscribers and Relying Parties described in Certificate Policy [22] and this CPSWSA-eIDAS, Fina accepts that the contracted suppliers of application software through which Fina Root CA are distributed, does not accept any liability or potential liability of Fina laid down by this CPSWSA-eIDAS or other document due to the issuance or maintenance of certificates or due to trust in the certificate by the Relying Party or others. This however does not apply to claims, damage or loss suffered in cases where the software supplier of application software has not carried out verification of the foundedness of achieving trust in the certificate or presented it incorrectly, and at the moment when the information about the current certificate revocation status was online accessible via the OCSP service and CRL.

The Subscriber is liable to the damaged party or any other participant if he/she procures and uses a certificate issued by Fina on the basis of fraudulently given data in the certificate issuance application.



The Relying Party is liable to the damaged party, that is, any other participant if it relies on the issued certificate without having checked its validity as described in Section 9.6.4 hereof, or if it uses it contrary to the purposes established in this CPSWSA-eIDAS.

9.10 Term and termination

9.10.1 Term

This CPSWSA-eIDAS document is valid until a new CPSWSA-eIDAS document comes into force or until its termination is published. A new document version or published termination of the current version shall be published on the website of the repository referred to in Section 2.2 hereof, with its established date of entry into force. The new CPSWSA-eIDAS document shall be assigned a new OID and it shall contain an indication of the modifications made thereto.

9.10.2 Termination

By entering into force of the new version of the CPSWSA-eIDAS document for all certificates issued according to this document, stipulations of this document that cannot be meaningfully replaced by the stipulations of the new version of the Certificate Policy document shall remain in force.

Termination of this CPSWSA-eIDAS document is not bound by nor it affects the validity of certificates issued under this document.

Fina may amend some provisions of the currently valid CPSWSA-eIDAS document as specified in Section 9.12 hereof.

9.10.3 Effect of termination and survival

When a new version of the CPSWSA-eIDAS document enters into force, the provisions of such document shall be applied to all certificates issued from that day on. Certificates issued under the previous CPSWSA-eIDAS documents shall be valid until their termination, but they may be renewed in accordance with the new CPSWSA-eIDAS document. 9.11 Individual notices and communication with participants Individual communication with participants is primarily conducted through the Fina Call Centre:

• call free of charge 0800 0080 Individual notifications and other official written communication is done using the following contact details:

Contact data for delivery of correspondence to Fina



Mailing address: Fina

e-Business Centre Ulica grada Vukovara 70 10000 Zagreb Croatia

E-mail: [email protected]

Fax: +385-1-6304-081

9.12 Amendments

9.12.1 Procedure for amendment

This CPSWSA-eIDAS document is revised as required.

Fina may correct spelling mistakes, change contact data and make other minor corrections not materially affecting the participants without notice to the participants.

All participants may send a letter to the Fina PMA contact address referred to in Section 1.50 hereof, containing a proposal for corrections or for the amendments to this CPSWSA-eIDAS document. Contact data of the person sending the modification proposal is included in the letter. Upon examination, Fina PMA may accept, adjust or reject proposed modifications.

Fina PMA shall approve and shall conduct the creation of a new or amending the existing CPSWSA-eIDAS document in accordance with the Fina business requirements and legislation stipulations referred to in Section 9.14 hereof.

9.12.2 Notification mechanism and period

All amendments to this CPSWSA-eIDAS document convenient for publication are published in electronic form on the website of the repository referred to in Section 2.2 hereof.

New versions and sub-versions of the public CPSWSA-eIDAS document with the amended OID of the CPSWSA-eIDAS document shall be published in electronic form on the website of the repository referred to in Section 2.2 hereof.

The effective date of amendments or newly-published CPSWSA-eIDAS document shall be indicated on its cover page as well as on the website where it shall be published.

9.12.3 Circumstances under which OID must be changed

Major amendments to the CPSWSA-eIDAS document that may materially affect the participants shall require the change of CPSWSA-eIDAS document OID. Fina PMA shall determine the new OID for the new CPSWSA-eIDAS document version.



9.13 Dispute resolution provisions

In the event of a dispute or disagreement between Fina and other participants due to actions and/or procedures regarding certification service provision regulated herein, the participants shall try to reach an amicable solution. Otherwise, the matter shall be resolved by the competent court in Zagreb by applying Croatian law.

Participants may forward a complaint to Fina if they believe there exist a discrepancy in the content of services in relation to the published terms and conditions of service provision. Fina shall reply to the complaint. Complaints are filed on in a paper or electronic form using contact details as described under Section 9.11 hereof.

9.14 Governing law

Fina provides qualified trust services within the scope of this CPSWSA-eIDAS in accordance with the provisions of Regulation (EU) No. 910/2014 [1], Act Implementing Regulation (EU) no. 910/2014 [2], and standardisation documents ETSI EN 319 401 [6] and ETSI EN 319 411-1 [7] and CA/Browser Forum BRG [19].

9.15 Compliance with applicable law

This CPSwsa-eIDAS document and certification services provision covered therein are in compliance with the provision referred to in Section 9.14 hereof.

All participants mutually agree with the application of Croatian law for interpretation of the applied provisions.

9.16 Miscellaneous provisions

Fina publishes this CPSWSA-eIDAS document, Certificate Policy [22] and the terms and conditions of the certification services.

The terms and conditions of the certification services are communicated through a document in paper or electronic form the integrity of which is protected.

Before concluding a Subscriber Agreement, Subscribers are informed about the terms and conditions of the certification services. Acceptance of the terms and conditions of the certification services is a prerequisite for certificate issuance.

In procedures for certificate renewal, certificate issuance after expiry, revocation or modifications to data in the certificate, Fina notifies the Custodian or Legal Representative about the possible amendments to the terms and conditions of the certification services.