Certificate Policy for Non-qualified Certificatesrdc.fina.hr › RDC2015 ›...

Certificate Policy for Non-qualified Certificates

Classification: Designation: 753604 Revision: 1-03/2017 Page: 1/100

FINA CERTIFICATE POLICY FOR NON-QUALIFIED

CERTIFICATES Version 1.0

Effective date: 22 May 2017 Document OID: 1.3.124.1104.5.0.4.1.1.0



Document Details

Document Name: Certificate Policy for Non-qualified Certificates

Document OID: 1.3.124.1104.5.0.4.1.1.0

Document Type: Certificate Policy (CP)

Distribution Designation Public

Document Owner: Financial Agency, Fina

Contact [email protected]

Amendment History

Version Date Reason for Change

1.0 22/05/2017 Initial version

mailto:[email protected]



CONTENTS

REFERENCE DOCUMENTED INFORMATION ...................................................................11

Core Legislation ................................................................................................................11 Subordinate Regulations ...................................................................................................11 Other Legislation ...............................................................................................................11 Standardization Documents ..............................................................................................12 Fina's Documents .............................................................................................................13

1. INTRODUCTION ...........................................................................................................14

1.1. Overview ................................................................................................................14 1.1.1. Certificate Policies ...........................................................................................15 1.1.2. Certificate Types ..............................................................................................15 1.1.2.1. Fina RDC 2015 Personal Certificates ...............................................................17 1.1.2.2. Fina RDC 2015 Business Certificates ..............................................................17 1.1.2.3. Fina RDC 2015 Business Certificates for IT Equipment ...................................18 1.1.2.4. Certificate for e-seal of Trusted List .................................................................18 1.1.2.5. Fina RDC 2015 Administrative Certificates ......................................................18 1.1.2.6. Fina RDC-TDU 2015 Certificates .....................................................................19

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

1.3.1. Certification authorities.....................................................................................19 1.3.2. Registration authorities ....................................................................................21 1.3.3. Subscribers ......................................................................................................21 1.3.3.1. Subjects ...........................................................................................................22 1.3.4. Relying parties .................................................................................................22 1.3.5. Other participants.............................................................................................22

1.4. Certificate usage .....................................................................................................22 1.4.1. Appropriate certificate uses ..............................................................................23 1.4.1.1. Appropriate Use of Personal Certificates .........................................................23 1.4.1.2. Appropriate Use of Business Certificates .........................................................23 1.4.1.3. Appropriate Use of Business Certificates for IT Equipment ..............................23 1.4.1.4. Appropriate TDU Certificates Uses ..................................................................23 1.4.2. Prohibited certificate uses ................................................................................23

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

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

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES ............................................33

2.1. Repositories ............................................................................................................33



2.2. Publication of certification information .....................................................................33 2.3. Time or frequency of publication .............................................................................34 2.4. Access controls on repositories ..............................................................................34

3. IDENTIFICATION AND AUTHENTICATION .................................................................35

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

3.2. Initial identity validation ...........................................................................................39 3.2.1. Method to prove possession of private key ......................................................39 3.2.2. Authentication of organization identity ..............................................................40 3.2.3. Authentication of an individual identity .............................................................40 3.2.3.1. Direct Identification Procedure .........................................................................41 3.2.3.2. Indirect Identification Procedure .......................................................................41 3.2.3.3. Eligible Types of identification Documents .......................................................41 3.2.4. Non-verified subscriber information ..................................................................41 3.2.5. Validation of authority ......................................................................................42 3.2.6. Criteria for interoperation .................................................................................42

3.3. Identification and authentication for re-key requests ...............................................42 3.3.1. Identification and authentication for routine re-key ...........................................43 3.3.1.1. Identification when Submitting an Application in the RA Network .....................43 3.3.1.2. Identification when Submitting an Online Application .......................................43 3.3.2. Identification and authentication for re-key after revocation ..............................43 3.3.3. Identification and authentication for re-key after expiry ....................................43 3.3.4. Identification and authentication for certificate recovery ...................................43

3.4. Identification and authentication for revocation and suspension request .................44 3.4.1. Identification and Authentication of Applicant for Revocation and Suspension .44 3.4.2. Identification and Authentication of Applicants for Certificate Reactivation .......45

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS ..................................46

4.1. Certificate Application .............................................................................................46 4.1.1. Who can submit a certificate application ..........................................................46 4.1.2. Enrolment process and responsibilities ............................................................46 4.1.2.1. Certificate Application Submission Process .....................................................47 4.1.2.2. Obligations and Responsibilities in the Certificate Application Process ............47

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

4.3. Certificate Issuance ................................................................................................48 4.3.1. CA actions during certificate issuance ..............................................................48 4.3.2. Notification to the Subscriber by the CA of Issuance of certificate ....................48

4.4. Certificate acceptance ............................................................................................49 4.4.1. Conduct constituting certificate acceptance .....................................................49



4.4.2. Publication of the certificate by the CA .............................................................49 4.4.3. Notification of certificate issuance by CA to other entities ................................49

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

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

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

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

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



4.10. Certificate status services .......................................................................................60

4.10.1. Operational characteristics ...............................................................................60 4.10.2. Service availability ...........................................................................................60 4.10.3. Optional features..............................................................................................61

4.11. End of subscription .................................................................................................61 4.12. Key escrow and recovery ........................................................................................61

5. FACILITY MANAGEMENT AND OPERATIONAL CONTROLS .....................................62

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

5.2. Procedural controls .................................................................................................64 5.2.1. Trusted roles ....................................................................................................64 5.2.2. Number of persons required per task ...............................................................64 5.2.3. Identification and authentication for each role ..................................................64 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 ...........................................................65 5.3.5. Job rotation frequency and sequence ..............................................................65 5.3.6. Sanctions for unauthorised actions ..................................................................65 5.3.7. Independent contractor requirements ...............................................................66 5.3.8. Documentation supplied to personnel ..............................................................66

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

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



5.6. Key changeover ......................................................................................................69 5.7. Compromise and disaster recovery ........................................................................69

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

5.8. CA or RA termination ..............................................................................................70 6. TECHNICAL SECURITY CONTROLS ..........................................................................72

6.1. Key pair generation and Installation ........................................................................72 6.1.1. Key pair generation ..........................................................................................72 6.1.1.1. Fina CA Key Pair Generation ...........................................................................72 6.1.1.2. RA Key Pair Generation ...................................................................................72 6.1.1.3. Subscriber key pair generation for NCP+ certificates .......................................73 6.1.1.4. Subscriber key pair generation for NCP certificates and LCP certificates .........74 6.1.2. Private key delivery to subscriber .....................................................................74 6.1.3. Public key delivery to CA .................................................................................75 6.1.4. CA public key delivery to Relying parties .........................................................75 6.1.5. Key sizes .........................................................................................................75 6.1.6. Public key parameters generation and quality checking ...................................75 6.1.7. Key usage purposes (as per X.509 v3 key usage field) ....................................76

6.2. Private Key Protection and Cryptographic Module Engineering Controls ................76 6.2.1. Cryptographic module standards and controls .................................................76 6.2.2. Private key (n out of m) multi-person control ....................................................77 6.2.3. Private key escrow ...........................................................................................77 6.2.4. Private key backup ...........................................................................................77 6.2.5. Private key archival ..........................................................................................77 6.2.6. Private key transfer into or from a cryptographic module ..................................78 6.2.7. Private key storage on cryptographic module ...................................................78 6.2.8. Method of activating private key .......................................................................78 6.2.9. Method of deactivating private key ...................................................................78 6.2.10. Method of destroying private key .....................................................................79 6.2.11. Cryptographic Module Rating ...........................................................................79

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

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

6.5. Computer security controls .....................................................................................81 6.5.1. Specific computer security technical requirements ...........................................81 6.5.2. Computer security rating ..................................................................................82

6.6. Life cycle technical controls ....................................................................................82 6.6.1. System development controls ..........................................................................82 6.6.2. Security management controls .........................................................................82 6.6.3. Life cycle security controls ...............................................................................83



6.7. Network security controls ........................................................................................83 6.8. Time-stamping ........................................................................................................83

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

7.1. Certificate profile .....................................................................................................84 7.1.1. Version number(s) ...........................................................................................84 7.1.2. Certificate extensions .......................................................................................84 7.1.3. Algorithm Object Identifiers (OID) ....................................................................84 7.1.4. Name forms .....................................................................................................84 7.1.5. Name constraints .............................................................................................84 7.1.6. Certificate policy object identifier ......................................................................85 7.1.7. Usage of policy constraints extension ..............................................................85 7.1.8. Policy qualifiers syntax and semantics .............................................................85 7.1.9. Processing semantics for the critical Certificate Policy extension .....................85

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

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

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS ..................................................87

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

8.2. Identity/qualifications of assessor ...........................................................................87 8.3. Assessor's relationship to assessed entity ..............................................................88 8.4. Topics covered by assessment ...............................................................................88 8.5. Actions taken as a result of deficiency ....................................................................88 8.6. Communication of results .......................................................................................88

9. OTHER BUSINESS AND LEGAL MATTERS ................................................................89

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

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

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

9.4. Privacy of personal information ...............................................................................91 9.4.1. Privacy plan .....................................................................................................91



9.4.2. Information treated as private...........................................................................91 9.4.3. Information not deemed private ........................................................................91 9.4.4. Responsibility to protect private information .....................................................91 9.4.5. Notice and consent to use private information ..................................................91 9.4.6. Disclosure pursuant to judicial or administrative process .................................92 9.4.7. Other information disclosure circumstances .....................................................92

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

9.6.1. CA representations and warranties ..................................................................92 9.6.2. RA representations and warranties ..................................................................94 9.6.3. Subscriber representations and warranties ......................................................94 9.6.4. Relying party representations and warranties ..................................................95 9.6.5. Representations and warranties of other participants .......................................96

9.7. Disclaimer of warranties ..........................................................................................96 9.8. Limitations of liability ...............................................................................................97 9.9. Indemnities .............................................................................................................97 9.10. Term and termination ..............................................................................................98

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

9.11. Individual notices and communication with participants ..........................................98 9.12. Amendments ..........................................................................................................99

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

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



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



REFERENCE DOCUMENTED INFORMATION

Core Legislation [1] Regulation (EU) No 910/2014 of the European Parliament and 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] Electronic Signature Act (Official Gazette (Croatian Official Gazette (hereinafter referred to as Official Gazette) 10/2002)

[3] Act on Amendments to the Electronic Signature Act (Official Gazette 80/2008) [4] Act on Amendments to the Electronic Signature Act (Official Gazette 30/2014)

Subordinate Regulations [5] Commission Implementing Decision (EU) 2015/1505 of 8 September 2015

laying down technical specifications and formats relating to trusted lists pursuant to Article 22(5) 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;

[6] Commission implementing Decision (EU) 2016/650 of 25 April 2016 laying down standards for the security assessment of qualified signature and seal creation devices pursuant to Articles 30(3) and 39(2) 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;

[7] Ordinance on the Registry of Certification Service Providers in the Republic of Croatia (Official Gazette 107/2010)

[8] Ordinance on the Creation of Electronic Signature, the Use of Signature Creation Devices and on General and Special Terms and Conditions for Providers of Time-stamping and Certification Services (Official Gazette 107/2010)

[9] Ordinance on Amendments to the Ordinance on the Creation of Electronic Signature, the Use of Signature Creation Devices and on General and Special Terms and Conditions for Providers of Time-stamping and Certification Services (Official Gazette 89/2013)

[10] Regulation on the Scope of Operations, Content and Responsible Authority for Operations of Electronic Signature Certification for State Administration Bodies (Official Gazette 146/2004);

Other Legislation [11] Act on Personal Data Protection (Official Gazette 106/2012-consolidated text)



Standardization Documents

[12] ISO/IEC 27001:2013 - Information technology — Security techniques — Information security management

[13] ISO/IEC 27002:2013 - Information technology - Security techniques - Code of practice for information security management

[14] ETSI EN 319 401 V2.1.1. (2016-02) – Electronic Signatures and Infrastructures (ESI); General Policy Requirements for Trust Service Providers

[15] 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

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

[17] ETSI EN 319 412-2 V2.1.1. (2016-02) – Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 2: Certificate profile for certificates issued to natural persons

[18] 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

[19] 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

[20] ETSI TS 119 312 V1.1.1. (2014-11) – Electronic Signatures and Infrastructures (ESI); Cryptographic Suites

[21] HRN EN 419 211-1:2014 – Protection profiles for secure signature creation device – Part 1: Overview (EN 419211-1:2014); Protection profiles for secure signature creation device – Part 1: Overview (EN 419211-1:2014)

[22] HRN EN 419 211-2:2013 – Protection profiles for secure signature creation device – Part 2: Device with key generation (EN 419211-1:2013); Protection profiles for secure signature creation device – Part 2: Device with key generation (EN 419211-2:2013)

[23] HRN EN 419 211-4:2013 – Protection profiles for secure signature creation device – Part 4: Extension for device with key generation and trusted channel to certificate generation application (EN 419211-4:2013); Protection profiles for secure signature creation device – Part 4: Extension for device with key generation and trusted channel to certificate generation application (EN 419211-4:2013)

[24] HRN EN 419 211-5:2013 – Protection profiles for secure signature creation device – Part 5: Extension for device with key generation and trusted channel to secure signature creation application (EN 419211-5:2013); Protection profiles for secure signature creation device – Part 5: Extension for device with



key generation and trusted channel to signature creation application (EN 419211-5:2013)

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

[26] IETF RFC 3647 – Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework

[27] IETF RFC 5280 (2008) – Internet X.509 Public Key Infrastructure; Certificate and Certificate Revocation List (CRL) Profile

[28] IETF RFC 6960 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP (2013)

[29] HRN ISO/IEC 9594-8:2015 - Information technology – Open Systems Interconnection – The Directory – Part 8: Public key and attribute certificates frameworks (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)

[30] CA/Browser Forum - Baseline Requirements - Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates

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

CP/CPSROOT [32] Certification Practice Statement for Non-qualified Certificates for Electronic

Signatures and Seals, CPSNQC-eIDAS



1. INTRODUCTION

Fina PKI was initially designed and established within the Financial Agency (Fina) as a Trusted Third Party with the aim of providing certification services to Natural persons - citizens, Business Entities and public authorities. As a Qualified Trust Service Provider, Fina shall enable the building of trust relationship necessary for the use and development of electronic business (e-Business) and electronic government (e-Government). By promoting these trust services and their use, Fina wishes to encourage and facilitate the development of e-Business and e-Government.

Fina, as a Croatian state-owned company with a semi-centennial tradition within the scope of financial services, is a state partner that cooperates with the Croatian National Bank and successfully does business with banks, numerous business systems and other Business Entities in the Republic of Croatia. Fina's IT system has been put to a test through the most demanding tasks of national importance, and highly professional expert teams have enabled the preparation and implementation of various projects.

Tradition, reliable service provision and orientation towards providing electronic services to Natural persons - citizens, Business Entities and public authorities are the main reasons why Fina has been recognized as a Trusted Third Party in e-Business and e-Government.

Fina’s business network covers branches and subsidiaries spread across the country, interconnected by an IT system that guarantees fast and reliable executions of demands that are also used by Fina Registration Authorities (FINA RA Network).

As a Trusted Third Party, Fina has provided certification services since 2003. Trust services provided by Fina are in accordance with legal regulations [1] – [11] and with applicable international standards within the scope of trust services provision. Fina shall continuously keep track of Subscribers' needs, technology development and modifications to standards within the scope of trust services provision, and improves and adjusts its PKI system accordingly, while putting efforts into adjusting its products and services to cross-border interoperability demands.

Non-qualified certificates issued by Fina shall be issued in accordance with this Certificate Policy.

1.1. Overview Fina PKI shall mean the PKI infrastructure established in Fina with which Fina provides trust services, and which refer to the issuance and management of production certificate life cycles (Hereinafter referred to as: certification services) and electronic time-stamp issuing.

The hierarchical structure of Fina PKI shall be based on the Fina Root CA and on a two-tier architecture of production Certification Authorities (hereinafter referred to as: CA or CAs).



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

• Root Certification Authority (root CA): Fina Root CA • two subordinated Certification Authorities:

o Fina RDC 2015; o Fina RDC-TDU 2015.

Fina Root CA has issued a self-signed Fina Root CA certificate and issued certificates to its subordinated Fina RDC 2015 and Fina RDC-TDU 2015 CAs.

The Policy referring to Fina Root CA and Fina PKI hierarchy based on Fina Root CA shall be described in the document Certificate Policy and Certification Practice Statement for Fina Root CA [31].

Fina RDC 2015 and Fina RDC-TDU 2015 CAs shall issue certificates for end-entities (hereinafter referred to as: Subscriber Certificates).

1.1.1. Certificate Policies

This Fina PKI - Certificate Policy for Non-qualified Certificates – CPNQC-eIDAS, hereinafter referred to as: “Certificate Policy”) shall contain the basic rules and set of principles for certification services provision by which Fina, as the Trust Service Provider, shall provide the services of issuing electronic signature certificates, authentication and key encryption (hereinafter referred to as: a non-qualified certificate or certificate).

The scope of this Certificate Policy shall be trust services provided by Fina, which refer to the issuance and management of life cycle of production non-qualified certificates that are issued as a software certificate whose private key shall be protected by a software token, or are issued on secure cryptographic devices, or are issued on QSCD devices or are issued for use in HSM modules.

The production certificate referred to within the scope of the Certificate Policy shall consist of the Register of Digital Certificates (Fina RDC), which consists of two Certification Authorities (CA) referred to within the scope of this Certificate Policy: Fina RDC 2015 and Fina RDC-TDU 2015. Hereinafter, where applicable, for simplicity's sake, Fina RDC 2015 and Fina RDC-TDU 2015 shall both be referred to as subordinated Fina CAs or just Fina CAs.

The purpose of this document shall be to define rules in the area outlined by the scope of this document, and according to which participants in Fina PKI listed in section 1.3 of this Certificate Policy shall act.

1.1.2. Certificate Types

This Certificate Policy shall define the certification rules for (non-qualified) certificates issued by Fina CAs that are harmonised 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).



This Certificate Policy shall define the certificates groups, certificate types and corresponding security levels. Certificates groups shall be determined by the Subject certification type. One group of certificates may have one or more certificate types. Each certificate type shall have an assigned Fina and ETSI OID certification policy (CP OID). With the aid of the CP OID, Signatories, Custodians and Relying parties shall determine the adequacy of certificates for specific use. Each certificate type shall have an assigned security level which shall determine the degree of reliance on the certificate.

The tables below show the groups and types of non-qualified certificates within the scope of this Certificate Policy, with the names of certificates and corresponding Fina and ETS OIDs of Certificate policy (hereinafter referred to as: CP OID). Table 1.1 shows the groups and types of non-qualified certificates issued by Fina RDC 2015, while Table 1.2 shows the groups and types of non-qualified certificates issued by Fina RDC-TDU 2015.

Non-qualified Certificates Issued by Fina RDC 2015 CA Name of Group

Certificate Name of Certificate

Type Fina and ETSI CP OID Security Level

Fina RDC 2015 Personal Certificates

Personal authentication certificate (NCP+)

Fina CP OID: 1.3.124.1104.5.12.11.4.2 ETSI CP OID: 0.4.0.2042.1.2 Medium

Personal soft certificate (NCP) Fina CP OID: 1.3.124.1104.5.12.11.3.1 ETSI CP OID: 0.4.0.2042.1.1 Standard

Fina RDC 2015 Business Certificates

Business authentication certificate (NCP+)


Business soft certificate (NCP) Fina CP OID: 1.3.124.1104.5.12.12.3.1 ETSI CP OID: 0.4.0.2042.1.1 Standard

Business soft certificate (LCP) Fina CP OID: 1.3.124.1104.5.12.12.5.1 ETSI CP OID: 0.4.0.2042.1.3 Standard

Fina RDC 2015 Business Certificates for IT equipment

Application Certificate Level 1 (NCP)

Fina CP OID: 1.3.124.1104.5.12.15.3.1 ETSI CP OID: 0.4.0.2042.1.1 Standard

Application Certificate Level 2 (NCP)

Fina CP OID: 1.3.124.1104.5.12.15.3.2 ETSI CP OID: 0.4.0.2042.1.1

Medium

Application Certificate Level 2 (NCP+)


Application Certificate Level 3 (NCP+)

Fina CP OID: 1.3.124.1104.5.12.15.4.3 ETSI CP OID: 0.4.0.2042.1.2 High

Certificate for e-seal of Trusted List

Certificate for e-seal of Trusted List (NCP+)


Fina RDC 2015 Administrative Certificates Administrative certificate (NCP+) Fina CP OID: 1.3.124.1104.5.12.16.4.2

ETSI CP OID: 0.4.0.2042.1.2 N/A

Table 1.1 Groups and Types of Non-qualified Certificates Issued by Fina RDC 2015



Non-qualified Certificates Issued by Fina RDC-TDU 2015 CA

Name of Group Certificate

Name of Certificate Type Fina and ETSI CP OID

Fina RDC-TDU 2015 Certificates

TDU authentication certificate (NCP+)


Table 1.2 Groups and Types of Non-qualified Certificates Issued by Fina RDC-TDU 2015

1.1.2.1. Fina RDC 2015 Personal Certificates

Fina RDC 2015 personal certificates shall be intended for Natural persons - citizens for electronic signing. This Certificate Policy shall determine the following types of personal non-qualified certificates:

• Personal Authentication Certificate (NCP+) – Personal authentication certificate of medium security level whose corresponding private key shall be kept in a secure cryptographic device or QSCD device, in accordance with Section 6.2.1 of this Certificate Policy. This type of certificate shall be compatible with "NCP+" Certificate policy referred to in standard ETSI EN 319 411-1 [15].

• Personal Soft Certificate (NCP) – Personal authentication certificate of standard security level whose corresponding private key shall be kept in software protected token, in accordance with Section 6.2.1 of this Certificate Policy. This type of certificate shall be compatible with "NCP" Certificate policy referred to in standard ETSI EN 319 411-1 [15].

1.1.2.2. Fina RDC 2015 Business Certificates

Fina RDC 2015 business certificates shall be intended for business use, and shall be issued to Natural persons associated with a Business Entity (hereinafter referred to as: Associated Person).

Fina RDC 2015 business certificates shall not be issued to state administration authorities, rather certificates for state administration authorities shall be issued on a separate Fina RDC-TDU 2015 CA in accordance with Section 1.1.2.6 of this Certificate Policy.

This Certificate Policy shall determine the following types of business certificates:

• Business Authentication Certificate (NCP+) – Business authentication certificate of medium security level whose corresponding private key shall be kept in a secure cryptographic device or QSCD device, in accordance with Section 6.2.1 of this Certificate Policy. This type of certificate shall be compatible with "NCP+" Certificate policy referred to in standard ETSI EN 319 411-1 [15].

• Business Soft Certificate (NCP) – Business authentication certificate of standard security level whose corresponding private key shall be kept in software protected token, in accordance with Section 6.2.1 of this Certificate Policy. This type of



certificate shall be compatible with "NCP" Certificate policy referred to in standard ETSI EN 319 411-1 [15].

• Business Soft Certificate (LCP) – Business authentication certificate for e-Signature, medium security level whose corresponding private key shall be kept in software protected token, in accordance with Section 6.2.1 of this Certificate Policy. This type of certificate shall be compatible with "LCP" Certificate policy referred to in standard ETSI EN 319 411-1 [15].

1.1.2.3. Fina RDC 2015 Business Certificates for IT Equipment

Fina RDC 2015 business certificate for IT equipment shall be issued for IT systems, applications or services associated with the Business Entity. Certificates for website authentication shall not be considered the business certificates for IT equipment within the scope of this Certificate Policy. This Certificate Policy shall determine the following types of business certificates for IT equipment:

• Application certificate level 1 (NCP) – Certificate of a standard security level whose corresponding private key shall be kept in a software protected token, in accordance with Section 6.2.1 of this Certificate Policy. This type of certificate shall be compatible with "NCP" Certificate policy referred to in standard ETSI EN 319 411-1 [15].

• Application certificate level 2 (NCP) – Certificate of a medium security level whose corresponding private key shall be kept in a software protected token, in accordance with Section 6.2.1 of this Certificate Policy. This type of certificate shall be compatible with "NCP" Certificate policy referred to in standard ETSI EN 319 411-1 [15].

• Application certificate level 2 (NCP+) – Certificate of a medium security level whose corresponding private key shall be kept in a cryptographic device or QSCD device, in accordance with Section 6.2.1 of this Certificate Policy. This type of certificate shall be compatible with "NCP+" Certificate policy referred to in standard ETSI EN 319 411-1 [15].

• Application certificate level 3 (NCP+) – Certificate of a high security level whose corresponding private key shall be kept in a HSM module, in accordance with Section 6.2.1 of this Certificate Policy. This type of certificate shall be compatible with "NCP+" Certificate policy referred to in standard ETSI EN 319 411-1 [15].

1.1.2.4. Certificate for e-seal of Trusted List

The Certificate for e-seal of Trusted List shall be used for electronic seal of Trusted List, and shall be issued to the central state administration body competent for economic affairs. The corresponding private key shall be kept in a secure cryptographic device or QSCD device, in accordance with Section 6.2.1 of this Certificate Policy. This type of certificate shall be compatible with "NCP+" Certificate policy referred to in standard ETSI EN 319 411-1 [15].

1.1.2.5. Fina RDC 2015 Administrative Certificates

The Administrative certificate (NCP+) shall be used by authorised Fina personnel. The corresponding private key of this certificate shall be kept in a secure cryptographic device or



QSCD device, in accordance with Section 6.2.1 of this Certificate Policy. This type of certificate shall be compatible with "NCP+" Certificate policy referred to in standard ETSI EN 319 411-1 [15].

1.1.2.6. Fina RDC-TDU 2015 Certificates

Fina RDC-TDU 2015 certificates shall be intended for use in TDU, and shall be issued to state officials and employees in state administration bodies (hereinafter referred to as: TDU).

• TDU authentication certificate (NCP+) – TDU authentication certificate of medium security level, issued to Associated persons whose corresponding private key shall be kept in a secure cryptographic device or QSCD device, in accordance with Section 6.2.1 of this Certificate Policy. This type of certificate shall be compatible with "NCP+" Certificate policy referred to in standard ETSI EN 319 411-1 [15].

1.2. Document name and identification British Standards Institution (BSI) International Code Designator (ICD) assigned an 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 shall be the name of this document and the corresponding identification data.

• Name: Certificate Policy for Non-qualified Certificates • Version: 1.0 • Effective date: 22 May 2017 • OID: 1.3.124.1104.5.0.4.1.1.0 • The internet addresses on which the document shall be published:

- http://rdc.fina.hr/RDC2015/FinaRDC2015-CPNQC1-0-en.pdf and - http://rdc.fina.hr/RDC-TDU2015/FinaRDC-TDU2015-CPNQC1-0-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 (LRA); • Subscribers; • Relying parties.

1.3.1. Certification authorities

Certification Authorities in Fina PKI under the scope of this Certificate Policy shall be Fina RDC 2015 and Fina RDC-TDU 2015 (Fina CAs). Fina, as a Trust Service Provider, through its Fina CAs carries out services of issuance and management of certificate life cycles in accordance with this Certificate Policy.

http://rdc.fina.hr/RDC2015/FinaRDC2015-CPNQC1-0-en.pdf

http://rdc.fina.hr/RDC-TDU2015/FinaRDC-TDU2015-CPNQC1-0-en.pdf



The obligations and responsibilities of Fina, which through its Fina CAs shall issue Subscriber certificates, are listed in Section 9.6.1 of this Certificate Policy, while certification procedures that Fina CAs perform with the aim of fulfilling the requirements referred to in this Certificate Policy shall be described in the CPSNQC-eIDAS [32] document.

1.3.1.1. Fina RDC 2015 CA

Fina RDC 2015 CA shall issue non-qualified certificates, referred to in Table 1.1 in Section of 1.1.2 hereof, to the public.

Administrative certificates and certificates for electronic seal of Trusted List referred to within the scope of this Certificate Policy shall not be considered certificates that Fina issues to the public.

Fina RDC 2015 shall issue non-qualified certificates according to the same rules for Fina authorised persons and for persons with trusted roles in Fina PKI.

The basic data on Fina RDC 2015 certificate are provided in Table 1.3.

Field Attribute Value

Issuer

commonName Fina Root CA

organizationName Financijska agencija

countryName HR

Validity notBefore Time of issuance of the certificate

notAfter Time of issuance of the certificate + 10 years

Subject

commonName Fina RDC 2015


countryName HR

Table 1.3 Fina RDC-TDU 2015 certificate basic data

Fina RDC 2015 CA-certificate shall be available at: http://rdc.fina.hr/RDC2015/FinaRDCCA2015.cer.

1.3.1.2. Fina RDC-TDU 2015 CA

Fina RDC-TDU 2015 has been established pursuant to:

• Article 30 of the Regulation on the Scope of Operations, Content and Responsible Authority for Operations of Electronic Signature Certification for State Administration Bodies [10].

Fina RDC-TDU 2015 shall issue non-qualified, certificates to state officials and employees in TDU. The non-qualified certificates issued by Fina RDC-TDU 2015 are listed in Table 1.2 in Section 1.1.2 of this Certificate Policy.

Fina RDC-TDU 2015 certificate basic data are provided in Table 1.4:

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



Field Attribute Value

Issuer

commonName Fina Root CA


countryName HR

Validity notBefore Time of issuance of the certificate

notAfter Time of issuance of the certificate + 10 years

Subject

commonName Fina RDC-TDU 2015


countryName HR

Table 1.4 Fina RDC-TDU 2015 CA certificate basic data

Fina RDC-TDU 2015 CA-certificate shall be available at:

http://rdc.fina.hr/RDC-TDU2015/FinaRDC-TDUCA2015.cer.

1.3.2. Registration authorities

Subscriber registration for Fina CAs shall be performed in Fina Registration Authorities. For the purpose of Subscriber registration for Fina CAs, Fina may outsource the provision of registration services to other Business Entities.

The Registration Authorities Network (hereinafter referred to as: RA Network) shall consist of Fina RA Network and the network of individual External RA.

Fina RA Network shall be comprised of the Local Registration Authority networks (hereinafter referred to as: Fina LRA) in Fina's business network and the Central Fina RA. Subscriber registration in the Fina RA Network shall be carried out by Fina LRA and may also be performed by the Central Fina RA.

External RA Network shall be the network of Local Registration Authorities of the Business Entity with which Fina shall enter into an agreement on registration services provision for Fina CAs. The RA Network shall be obliged to perform registration tasks in accordance with this Certificate Policy.

The registration of Subscribers in the RA Network shall be carried out by authorised persons to whom the trusted role of Registration officer has been assigned.

Registration tasks in the RA Network shall be coordinated by the Central Fina RA.

The obligations and responsibilities of the Fina RA Network and the External RA shall be listed under Section 9.6.2 of this Certificate Policy.

1.3.3. Subscribers

A Subscriber shall be a Business Entity or Natural person - citizen who, by concluding an agreement with Fina as a Trust Service Provider, has undertaken the agreed obligations of a Subscriber.

http://rdc.fina.hr/RDC-TDU2015/FinaRDC-TDUCA2015.cer



In order to use certification services, Subscribers shall carryout the registration procedure and submit their applications, and shall accept the Subscriber obligations and responsibilities referred to in Section 9.6.3 of this Certificate Policy. Subscribers shall conclude a Subscriber agreement with Fina.

1.3.3.1. Subjects

In the certificate, the certification Subject shall be identified as the Subject and shall be the holder of the private key connected to the public key contained in the certificate.

The certification Subject in certificates issued by Fina RDC 2015:

• in personal certificates shall be a Natural person - citizen, • in business certificates shall be the Associated person of the Business Entity, • in business certificates for IT equipment shall be the IT system, application or device, • in certificates for the electronic seal of Trusted List shall be the central state

administration authority competent for economic affairs.

The certification Subject in certificates issued by Fina RDC-TDU 2015 shall be the Associated person of the TDU.

1.3.4. Relying parties

Relying parties shall be Natural persons – citizens or Business Entities relying on trust services. By means of the certificate, the Relying Party shall verify the identity of the Subject and shall validate electronic signatures.

1.3.5. Other participants

No stipulations.

1.4. Certificate usage The Relying Party shall be responsible for acceptance and achievement of reasonable reliance on the certificate which shall have a specific security level.

Table 1.5 provides a description of the security levels for non-qualified certificates issued by Fina CAs. For each security level, the Table shows the corresponding description of the area of application and the recommended financial limit.

Security level Area of application Recommended

financial limit

Standard This level shall be adequate for transactions of lesser value and in environments in which potential certificate misuse may cause minor damage or where certificate misuse risk shall be small.

up to HRK 8,000.00

Medium This level shall be 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 shall be moderate.

up to HRK 80,000.00



Security

level Area of application Recommended financial limit

High This level shall be 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 shall be large.

up to HRK 400,000.00

Table 1.5 Levels of Security for Non-qualified Certificates

1.4.1. Appropriate certificate uses

1.4.1.1. Appropriate Use of Personal Certificates

The personal certificates listed in Table 1.1 of this Certificate Policy shall be used by Natural persons - citizens for support in electronic signatures, for strong authentication and key encryption. These certificates and corresponding private keys shall be adequate for support and creation of an advanced electronic signature which is not based on a qualified certificate.

1.4.1.2. Appropriate Use of Business Certificates

The business certificates listed in Table 1.1 of this Certificate Policy shall be used by Associated persons for support in electronic signatures, for strong authentication and key encryption. These certificates and corresponding private keys shall be adequate for support and creation of an advanced electronic signature which is not based on a qualified certificate. Business certificates shall be used for business purposes.

1.4.1.3. Appropriate Use of Business Certificates for IT Equipment

The business certificates for IT equipment listed in Table 1.1 of this Certificate Policy shall be used by Business Entities for support in electronic signatures, for strong authentication and key encryption. These certificates shall be used for business purposes.

1.4.1.4. Appropriate TDU Certificates Uses

The TDU authentication certificate (NCP+) listed in Table 1.2 of this Certificate Policy shall be used by Associated persons in TDU for support in electronic signatures, for strong authentication and key encryption. These certificates and corresponding private keys shall be adequate for support and creation of an advanced electronic signature which is not based on a qualified certificate. This type of certificates shall be used for the needs of state administration bodies.

1.4.2. Prohibited certificate uses

Aside from the uses listed in Section 1.4.1 hereof, all other uses of certificates issued in accordance with this Certificate Policy shall be prohibited.



1.5. Policy administration

1.5.1. Organization administering the document

Fina shall remain authorized and responsible for creation and update of this Certificate Policy 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 this Certificate Policy 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 Certificate Policy are given below.

Mailing address: Fina Sektor financijskih i elektroničkih usluga Ured za upravljanje politikom e-poslovanja Koturaška cesta 43 10000 Zagreb Croatia

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

1.5.3. Person determining CPS suitability for the policy

Compliance of CPSNQC-eIDAS [32] with this Certificate Policy is determined by Fina PMA.

1.5.4. CPS approval procedures

The procedure for approval of the CPSNQC-eIDAS [32] document which shall confirm its compliance with this Certificate Policy shall be described in the CPSNQC-eIDAS [32] document.




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 shall know or possess.

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.

Associated Person Natural person employed at the Business Entity or otherwise associated with the Business Entity, and who is authorized by the same Business Entity to receive certificates. Such certificate identifies both the person and the Business Entity, and indicates that the person is associated with the Business Entity.

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.

Authorised Representative Natural person authorised legally or by proxy to represent the Creator of a seal in the issuance procedure and/or revocation of the Certificate for Electronic Seal.



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 seal Electronic attestation that connects the electronic seal validation data with the legal person and confirms the name of that person.

Certificate for electronic signature

An electronic attestation which links electronic signature validation data to a natural person and confirms at least the name or the pseudonym of that person.

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

Certificate Reactivation An action that shall make a suspended certificate valid again from the moment of reactivation.

Certificate Revocation An action that shall make 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.



TERM MEANING

Certificate Suspension An action that makes a certificate invalid from the moment of suspension. Suspended certificate may be reactivated and thus made valid again.

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

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

Certification Authority may be: 1. a trust service provider that creates and assigns public key

certificates; or 2. a technical certificate generation service that is used by a

certification service provider that creates and assign 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 shall be equivalent to mean solar time of the Prime Meridian (0°). More precisely, UTC shall be 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).

Creator of a Seal A legal person who creates an electronic seal.

Cryptographic Module Software or device of a certain security level which shall: generate a key pair and/or protect cryptographic information, and/or perform cryptographic functions.



TERM MEANING

Custodian A natural person employed at the Business Entity or associated in another way with the Business Entity, and who has been authorised by the same Business Entity 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 shall be authorised to submit requests for lifecycle management of certificates

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

Digital Signature Data added to the dataset or cryptographic transformation of the dataset enabling it's recipient to prove authenticity and integrity of the dataset and protecting the dataset from forgery, e.g. by the recipient.

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.

Electronic Seal Data in electronic form, which is attached to or logically associated with other data in electronic form to ensure the latter’s origin and integrity.

Electronic Seal Creation Data Unique data, which is used by the creator of the electronic seal to create an electronic seal.

Electronic Seal Creation Device Configured software or hardware used to create an electronic seal.

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 Signature Creation Device

Configured software or hardware used 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.



TERM MEANING

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

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

LCP certificate Certificate in accordance with Lightweight Certificate Policy).

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

Natural person - citizen Natural person requesting the certification service for the purpose of the use of the certificate for and on her/his own behalf, and excluding any natural person with registered business activity, any self-employed natural person and any natural person acting for and on behalf of another natural or legal person (Associated Person).

NCP Certificate A certificate aligned with Normalised Certificate Policy.

Policy Management Authority (PMA)

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

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

QSCD Device Qualified Electronic Signature/Seal Creation Device (see term "Qualified Electronic Signature Creation Device" or "Qualified Electronic Seal Creation Device").

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

Qualified Certificate for the Electronic Signature

Electronic signature certificate issued by a Qualified Trust Service Provider that meets the requirements established in Annex I of Regulation (EU) No 910/2014 [1].



TERM MEANING

Qualified Electronic Signature An advanced electronic signature that is created by a qualified electronic signature creation device, and which is based on a qualified certificate for electronic signatures.

Qualified Electronic Signature Creation Device

An electronic signature creation device that meets the requirements laid down in Annex II of the Regulation (EU) No 910/2014 [1].

Qualified Electronic Time Stamp

Electronic Time-Stamp that meets the following requirements:

(a) it binds the date and time to data in such a manner as to reasonably preclude the possibility of the data being changed undetectably;

(b) it is based on an accurate time source linked to Coordinated Universal Time; and

(c) it is signed using an advanced electronic signature or sealed with an advanced electronic seal of the qualified trust service provider, or by some equivalent method.

Qualified Trust Service Provider

Trust Service Provider that provides one or more qualified trust services and is granted the qualified status by the supervisory body.

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.

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.



TERM MEANING

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 or public cryptographic keys, used for the purpose of verifying a signature.

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 secure operation of the trust service provider. Trusted Roles and the corresponding responsibilities shall be 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.

Table 1.6 Definitions



1.6.2. Abbreviations

Table 1.7 Abbreviations

ABBREVIATION FULL NAME

CA Certification Authority

CP Certificate Policy

CPNQC-eIDAS Certificate Policy for Non-Qualified Certificates

CPS Certification Practice Statement

CPSNQC-eIDAS Certification Practice Statement for Non-Qualified Certificates

CRL Certificate Revocation List

DN Distinguished Name

LCP Lightweight Certificate Policy

LDAP Lightweight Directory Access Protocol

LRA Local Registration Authority

NCP Normalized Certificate Policy

NCP+ Extended Normalized Certificate Policy

OCSP On-line Certificate Status Protocol

OID Object Identifier

PIN Personal Identification Number

PKI Public Key Infrastructure

PMA Policy Management Authority

QSCD Qualified electronic Signature/Seal Creation Device

RA Registration Authority

TDU State Administration Body (Bodies)

UTC Coordinated Universal Time



2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1. Repositories The Fina PKI repository shall be managed by Fina as a Certification Service Provider. Fina shall be responsible for the operation of Fina PKI repositories and for the publication of documents and information about repositories.

Fina shall ensure repository availability 24 hours a day, 7 days a week.

2.2. Publication of certification information Documents and information on certification services provision shall be available to the public and shall be published on the Fina PKI repository.

The repository shall consist of a part available on websites and part available via the public LDAP registry.

The following shall be published on Fina PKI repository web pages: • Certification Policy documents, • public versions of the Certification Practice Statement, • Terms and Conditions and PKI disclosure statement, • Certification services price list, • Subscriber forms, • Fina Root CA certificate and subordinated Fina CAs certificates, • CRL Fina Root CA and CRLs subordinated Fina CAs, • certificates intended for verification and testing, • notifications to Subscribers and Relying parties, related to Certification Service

Provision, • results of external compliance audits, • other information related to the work of Fina CAs.

Each issued certificate may be retrieved from the Fina PKI repository website.

The website of the Fina PKI repository shall be available at http://www.fina.hr/finadigicert in Croatian and English.

Certificates of subordinated Fina CAs and CRLs issued by subordinated Fina CAs shall be accessible in the part of the Fina PKI repository accessible through the public LDAP Registry.

Address of the public LDAP Registry:

• for Fina RDC 2015 shall be ldap://rdc-ldap2.fina.hr; • for Fina RDC-TDU shall be ldap://rdc-tdu-ldap2.fina.hr.

Information on the status of issued certificates that are issued by Fina CAs shall be available via Fina OCSP service. Address of the Fina OCSP service shall be http://ocsp.fina.hr.

http://www.fina.hr/finadigicert

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

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

http://ocsp.fina.hr/



Confidential data shall not be published in the Fina PKI repository.

2.3. Time or frequency of publication Annually and according to needs, Fina shall maintain and update the Certificate Policy and Certification Practice Statement, and it shall approve and publish them. Other Fina PKI documents and other relevant information shall be published as required, after approval.

Certificates shall be available on the internet pages of Fina PKI repositories immediately upon issuance.

The frequency of publishing CRLs for certificates issued by Fina CAs shall be defined in Section 4.9.7 of this Certificate Policy.

Online information on the status of issued certificates shall be available via the Fina OCSP service described in Section 4.9.9 of this Certificate Policy.

2.4. Access controls on repositories Documents and information published on the Fina PKI repository shall be free and publicly accessible to read only.

On the repository, Fina has established control of access with the aim of preventing unauthorised addition, change or deletion of information and protection of its integrity and authenticity.

Fina authorised persons shall be entitled to add, change or delete information on the Fina PKI repository.



3. IDENTIFICATION AND AUTHENTICATION

3.1. Naming

3.1.1. Types of names

Details about the name, or the title of the certification Subject and details about the place of residence of a Natural person, or Business Entity registered office location shall be entered on each certificate. Details about the name or title entered in the certificate shall refer to the authentic name or title of the Subject. The Subject field in the certificate shall be aligned with the recommendation IETF RFC 5280 [27].

The Subject field in personal certificates and business certificates issued to Associated persons, shall contain the name and surname of the persons, and the serial number which shall ensure the uniqueness of the Subject field. In business certificates for Associated persons, the Subject field shall additionally contain the full registered name of the Business Entity and its identifier.

The Subject field in application certificates shall contain the name of the IT system, application or service (hereinafter referred to as: the application name). The Subject field in application certificates shall additionally also contain the full registered name of the Business Entity and its identifier.

The Subject field in certificates for electronic seal of Trusted List shall contain the full registered name and identifier of the central state administration authority competent for economic affairs.

The Subject field in Administrative certificates issued to authorised employees of Fina for internal use shall contain the name and surname of the person and serial number that shall ensure the uniqueness of the Subject field, and shall additionally also contain the full registered name of Fina and its OIB.

3.1.2. Need for names to be meaningful

The names and titles of attributes of the Subject field that identify Natural persons and Business Entities shall be meaningful.

The following rules shall apply to attributes in the Subject field in certificates issued by Fina CAs:

• identifiers must be meaningful, • the personal name and surname must be as listed in the identification document, that

is, official competent registers, • the full registered name of the Business Entity must be as listed in official competent

registers, • the name of the application must be as listed in applications for certificate issuance.



The content of certificate extensions Subject Alternative Name may be the Subject's email address which does not need to be meaningful.

3.1.3. Anonymity or pseudonymity of subscribers

Anonymity or pseudonyms of Subscribers shall not be supported.

3.1.4. Rules for interpreting various name forms

The interpretation of the name form in the Subject field according to the standard X.520 u Fina PKI shall be determined in the following way:

• Serial Number

The value of the attribute Serial Number in the Subject field shall guarantee the uniqueness of individual Subjects. The value of this attribute shall also guarantee the uniqueness of the Subject field in certificates within Fina PKI production hierarchy founded on Fina Root CA.

In personal and business certificates issued to Natural persons, the attribute Serial Number shall consist of a two-letter ISO code of the Signatory's country of residence, an 11-digit unique identifier of Natural persons and two numbers W and Z that shall represent designations that have internal meaning for Fina PKI. The 11-digit unique identifier of Natural persons shall be the OIB if a Natural person has an OIB assigned in the Republic of Croatia. If a Natural person does not have an assigned OIB, then the 11-digit unique identifier of the Natural person shall be generated by Fina.

In certificates for the electronic seal of Trusted List, the value of this attribute shall consist of two components: W and Z separated by a point. The W component shall be selected by the central state administration authority competent for economic affairs. The Z component has an internal meaning for Fina PKI.

In application certificates this field shall not be used.

• Common Name

In personal certificates and business certificates issued to Associated persons and in Administrative certificates, these attributes shall contain the name and surname of the Natural persons as listed in the identification document.

In application certificates this attribute shall contain the unique application name.

In certificates for the electronic seal of Trusted List this attribute shall contain the name determined by the central state administration authority competent for economic affairs, with which the Subject usually presents itself.



• Given Name

The attribute Given Name shall contain the name of the Natural person as listed in the identification document.

• Surname

The attribute Surname shall contain the surname of the Natural person as listed in the identification document.

• Organizational Unit Name

In certificates for TDU this attribute shall contain the name of organisational units connected with the TDU named in the attribute Organization Name.

• Organization Name

In personal certificates, the attribute Organization Name shall contain the value "OSOBNI".

In business certificates issued to Associated persons, the attribute Organization Name shall contain the full registered name of the Business Entity.

In application certificates, the attribute Organization Name shall contain the full registered name of the Business Entity.

In certificates for e-seal of Trusted List, this attribute shall contain the full registered name of the central state administration authority competent for economic affairs.

In Administrative certificates, the attribute Organization Name shall contain the full registered name of Fina.

• Organization Identifier

In business certificates issued to Associated persons and application certificates, the attribute Organization Identifier shall contain a two-letter ISO country code of the Business Entity's registered office and an 11-digit unique identifier of the Business Entity. The 11-digit unique of a Business Entity shall be the OIB if the Business Entity has a OIB assigned in the Republic of Croatia. If a Business Entity does not have an assigned OIB, then the 11-digit unique identifier of the Business Entity shall be generated by Fina.

In certificates for the electronic seal of Trusted List, the attribute of the Organization Identifier shall contain the designation "VAT", a two-letter ISO country code for the Republic of Croatia, and OIB of the central state administration authority competent for economic affairs. For Business Entities whose registered office shall be in the Republic of Croatia, the tax identification number shall be the OIB.

In Administrative certificates, the attribute Organization Identifier shall contain the two-letter ISO code of the country for Croatia and OIB of Fina.



• Locality Name

In business certificates, the attribute Locality Name shall contain the name of the locality in which the registered office of the Business Entity is located.

In personal certificates, the attribute Locality Name shall contain the place of residence of the Signatory.

In application certificates, the attribute Locality Name shall contain the name of the locality in which the registered office of the Business Entity is located.

In certificates for the electronic seal of Trusted List, the attribute Locality Name shall contain the name of the locality in which the registered office of the central state administration authority competent for economic affairs is located.

In Administrative certificates, the attribute Locality Name shall contain the name of the locality in which the registered office of Fina is located.

• Country Name

The attribute Country Name shall contain the designated two-letter ISO code of the Republic of Croatia.

• Subject Alternative Name

The Subject Alternative Name shall be an optional extension of the certificate that may only contain the email address of the Signatory, that is, the email address connected with the IT system, application or service in a form that complies with recommendation IETF RFC 822.

3.1.5. Uniqueness of names

The Distinguished Name of a Subject shall be unique within the Fina PKI production hierarchy based on Fina Root CA.

The uniqueness of a Distinguished Name in personal certificates and business certificates issued to Associated persons shall be ensured through the value of the attribute Serial number in the Subject field of the certificate.

In application certificates, the uniqueness of the name shall be ensured by entering the application name into the Common Name attribute of the distinguished certificate name, which must be unique within the same Business Entity.

In certificates for the electronic seal of Trusted List, the uniqueness of a name shall be ensured through the value of the attribute Serial Number in the Subject field of a certificate.

The uniqueness of a Distinguished Name in Administrative certificates shall be ensured through the value of the attribute Serial number in the Subject field of the certificate.



3.1.6. Recognition, authentication, and role of trademarks

In the event that the Subscriber request the issuance of a certificate that contain the trademark, the RA Network shall verify the legitimate use of the trademark and in the event of a founded complaint shall be entitled to revoke such a certificate.

In the event that the Subscriber requests the issuance of a certificate containing a trademark, the RA Network may request proof of registration of the trademark with a competent authority.

3.2. Initial identity validation Fina shall collect personal data of Natural persons and Business Entities exclusively for the needs of registration, for the purpose of issuing certificates.

Fina shall conduct verification of data collected in the Subscriber registration procedure by comparing this data with that in the submitted documentation, and insofar as it shall be applicable through the use of communication channels in accordance with valid legislation.

Upon the issuance of normalised NCP+ and NCP certificates within the scope of this Certificate Policy, Fina shall verify and confirm the identity of Natural persons on the basis of direct physical identification or by using methods that provide the same level of security as determining identity.

Upon issuance of LCP certificates within the scope of this Certificate Policy, Fina shall verify and confirm the identity of the Signatory by verifying data from the stipulated documentation collected, and according to Fina procedures for carrying out the Subscriber registration procedure.

3.2.1. Method to prove possession of private key

A private key that corresponds to a public key submitted for the creation of a certificate shall be generated by a Signatory, Custodian or Creator of a seal, or it shall be generated by Fina.

In the event that Fina shall generate a Subscriber key pair, through technological processes and verification methods it shall connect the Signatory, Custodian or Creator of a seal with the private key that corresponds to the public key for which Fina shall issue a certificate, as well as control of the private key by the Signatory or Authorised representative.

In the event that the Signatory or Custodian shall generate a key pair, Fina shall, by means of technological processes and by requesting certificates, include verification of whether a Signatory or Custodian possesses or controls a private key connected with a public key, which in a secure way shall be delivered to Fina for certificate creation.

In the event that the Certificate policy stipulates that for a specific type of certificate, the generation and protection of private keys shall be carried out with a secure cryptographic device or QSCD device, Fina or the External RA shall through technological processes and verification methods ensure that the public key submitted for certification is from a key pair



generated in a secure cryptographic or QSCD device, and that it shall be connected with a Signatory's private key, or a private key controlled by a Custodian or Creator of a seal.

3.2.2. Authentication of organization identity

The verification and authentication of a Business Entity's identity shall be conducted by verifying:

• the registered name of the Business Entity, • the legal existence of the Business Entity, • entry in the competent register, • the company registration number in the competent register, • the OIB of the Business Entity, if one has been assigned, • the address of the registered office of the Business Entity.

Fina does not carry out verification and authentication of Business Entities when issuing Administrative certificates to Fina's authorised employees.

3.2.3. Authentication of an individual identity

The initial identification and authentication of a Natural person's identity shall be carried out by collecting and verifying personal details using direct or indirect identification methods.

For the needs of initial identification and authentication of Natural persons, Fina shall collect and verify the following personal details:

• Name and surname: • date, place and country of birth, • OIB (if a OIB has been assigned), • details about the identification document referred to in Section 3.2.3.3 of this

Certificate Policy, • mailing address, • E-mail address, • Telephone number.

When issuing business certificates being issued to Associated persons, Fina shall also collect proof of the connection of the Associated person with the Business Entity.

When issuing application certificates, shall Fina also collect proof of the connection of the Custodian with the Business Entity.

When issuing certificates for the electronic seal of Trusted List, Fina shall also collect proof of connection of the Authorised representative with the central state administration authority competent for economic affairs.



3.2.3.1. Direct Identification Procedure

The direct identification of Natural persons shall be carried out in his/her physical presence on the basis of valid identification documents referred to in item 3.2.3.3 of this Certificate Policy.

3.2.3.2. Indirect Identification Procedure

The indirect identification procedure for a Natural person may be carried out in a way that provides the same security level of establishing the identity of a Natural person as the direct identification procedure.

When issuing normalised NCP and NCP+ certificates referred to within the scope of this Certificate Policy, Fina shall conduct the indirect identification procedure for Natural persons with the aid of Qualified Certificate for the Electronic Signatures issued on the basis of direct identification of Natural persons.

Fina may also conduct the indirect identification procedure for Natural persons with the aid of electronic identification devices, for which, before issuing the certificate, the physical presence of the Natural person has been secured and who meets the requirements in relation to the security level "significant" or "high" in accordance with the provisions of Article 8 of Regulation (EU) No 910/2014 [1].

Upon issuing LCP certificates within the scope of this Certificate Policy, Fina shall verify and confirm the identity of a Signatory on the basis of a copy of two different identification documents of the Signatory requesting the issuance of a LCP certificate.

3.2.3.3. Eligible Types of identification Documents

a) Applicants requesting the issuance of NCP and NCP+ certificates, and certificates for an electronic seal of Trusted List shall prove their identity with a valid ID card or passport.

b) Applicants requesting the issuance of LCP certificates, shall prove their identity with a valid ID card, passport, driver’s license or equally valid identification document with a photo, signature and with their personal details issued by the competent state authority in the country in which the document was issued, in accordance with the legislation of that country.

Natural persons who do not have an ID card or passport issued in the Republic of Croatia, shall prove their identity with a valid identification document with which they entered the Republic of Croatia.

3.2.4. Non-verified subscriber information

Non-verified Subscriber information shall be:

• TDU organization unit name,



• contact telephone numbers, in cases of submitted applications for issuing personal

and business normalized NCP+ and NCP certificates, • contact E-mail address.

Note!

Contact telephone numbers shall be verified in the procedure of verifying documentation collected for issuing LCP certificates.

3.2.5. Validation of authority

Before issuing business certificates to Associated persons, application certificates and TDU certificates, the identity of Legal Representative, i.e. persons authorised for representation shall be confirmed by verifying data from submitted documentation for legal personality determination of the Business Entity listed in Section 3.2.2, and by comparing these to data from copies of valid identification documents of Legal Representative, i.e. the person authorised for representation.

Identification of proxies shall be carried out in the same way as authentication of the person authorised for representation.

When issuing certificates for electronic seal of Trusted List, authentication of the Authorised representative shall be carried out using direct and indirect identification procedures in accordance with Sections 3.2.3.1 and 3.2.3.2 of this Certificate Policy.

Fina does not carry out identification of authorised persons when issuing Administrative certificates to authorised employees.

3.2.6. Criteria for interoperation

No stipulations.

3.3. Identification and authentication for re-key requests Fina shall carry out identification procedures and authentication of applicants for:

• 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 corresponding certification terms and conditions referred to in Section 9.16 of this Certificate Policy have changed since the issuing of the certificate which is the subject of certificate renewal, the actual certification terms and conditions shall be communicated to the Signatory, Custodian or Authorised representative, who shall accept these before issuing the certificate.



3.3.1. Identification and authentication for routine re-key

Routine certificate renewal shall be carried out before the end of the certificate life cycle and shall include the procedure for generating a Subscriber's new key pair (see Sections 4.6 and 4.7).

Routine certificate renewal shall be carried out if all the terms and conditions referred to in Section 4.7.1 of this Certificate Policy have been met.

3.3.1.1. Identification when Submitting an Application in the RA Network

The identification and authentication of applicants shall be carried out by submitting a personally signed application in paper form along with direct identification of the applicant in the RA Network and comparison of data from the application with data in Fina's database of registered Subscribers, and insofar as it shall be applicable by using communication channels in accordance with valid legislation.

3.3.1.2. Identification when Submitting an Online Application

For applicant identification and authentication during routine certificate renewal, which is conducted by submitting an online application, documentation and data for verifying the identity of Natural persons that were collected during the last direct identification of the applicant in the RA Network in accordance with Section 3.3.1.1 of this Certificate Policy may be used, under the condition that no more than six years have passed since the last direct identification of the applicant. The set of data in the application for certificate renewal shall be electronically signed using an advanced electronic signature or seal, and the certificate whose renewal is being requested.

Otherwise, the procedure in accordance with Section 3.3.1.1 of this Certificate Policy shall be carried out.

3.3.2. Identification and authentication for re-key after revocation

Identification and authentication of applicants for renewal after revocation shall be carried out in accordance with the procedure for initial identification referred to in Section 3.2 of this Certificate Policy.

3.3.3. Identification and authentication for re-key after expiry

Identification and authentication of applicants for renewal after expiry shall be carried out in accordance with the procedure for initial identification referred to in Section 3.2 of this Certificate Policy.

3.3.4. Identification and authentication for certificate recovery

Certificate recovery shall be conducted for the reason and under the terms and conditions referred to in Section 4.7.1 of this Certificate Policy.



Identification and authentication of applicants for certificate recovery shall be carried out in accordance with the procedure for initial identification referred to in Section 3.2 of this Certificate Policy.

3.4. Identification and authentication for revocation and suspension request Fina shall carry out revocation and suspension of certificates on the basis of submitted applications. Authentication of applicants shall be carried out to establish the identity of the Natural person as the applicant and to determine whether that person is authorised to submit an application.

3.4.1. Identification and Authentication of Applicant for Revocation and Suspension

Fina or the External RA shall carry out identification and authentication of applicants for revocation or suspension of certificates depending on the way in which the application shall be submitted:

• Personal delivery of the revocation or suspension request to the RA Network

Identification and authentication shall be carried out using the procedure for direct identification of the applicant on the basis of the identification documents of the applicant.

• Mail or courier delivery of the revocation or suspension request

Applicant identification and authentication shall be carried out at RA Network on the basis of a copy of the Applicant's ID document delivered together with the revocation or suspension application.

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

Identification and authentication of applicants shall be carried out through verification and validation of data of an advanced electronic signature in an electronically submitted application to the e-mail address listed in Section 9.11 of this Certificate Policy.

• Revocation or suspension request by phone

A certificate revocation or suspension request by phone shall be delivered by calling the Fina’s telephone number published on the website of the repository referred to in Section 2.2 of this Certificate Policy, 24 hours a day, 7 days a week.

If the initial certificate application has been submitted to the External RA, then the suspension request by phone shall be delivered by calling the External RA customer call centre during service hours.

The authorised employee who receive the telephone request shall run the Applicant identification and authentication procedure based on an enquiry and comparison of answers with the records stored in the RA system.



• Revocation or suspension request by telefax

Fina does not support the revocation procedure by telefax.

Applicant identification and authentication for certificate suspension shall be carried out on the basis of a copy of an applicant's ID document delivered by telefax together with the suspension request. The telefax number shall be listed in Section 9.11 of this Certificate Policy.

3.4.2. Identification and Authentication of Applicants for Certificate Reactivation

Authentication of applicants shall be carried out to establish the identity of a Natural person as the applicant and to determine whether that person is authorised to submit a request.

Fina or the External RA shall carry out identification and authentication of applicants for reactivation of certificates depending on the way in which the request is submitted:

• Personal delivery of the reactivation request to the RA Network

Identification and authentication shall be carried out using the procedure for direct identification of the applicant on the basis of the identification documents of the applicant.

• Mail or courier delivery of the reactivation request

Applicant identification and authentication shall be carried out at RA Network on the basis of an Applicant's ID document copy delivered together with the reactivation application.

• Electronic delivery of the reactivation request to an e-mail address

Identification and authentication of applicants shall be carried out through verification and validation of data of an advanced electronic signature in an electronically submitted application to the e-mail address listed in Section 9.11 of this Certificate Policy.



4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1. Certificate Application

4.1.1. Who can submit a certificate application

A certificate application may be submitted by the following Subjects, unless otherwise provided for in laws and acts adopted on the basis of such laws.

An application for issuing personal certificates may be submitted by Natural persons - citizens.

An application for issuing business certificates shall be submitted by Associated persons.

An application for issuing TDU certificates shall be submitted by Associated person of the TDU.

An application for issuing application certificates shall be submitted by the Custodian.

An application for issuing certificates for electronic seal of Trusted List may only be submitted by the Authorised representative of the central state administration authority competent for economic affairs.

Administrative certificates within the scope of this Certificate Policy shall only be issued to authorised Fina′ employees.

4.1.2. Enrolment process and responsibilities

An application for issuance of a certificate must be submitted for each new certificate issuance.

Prior to the initial issuance of each certificate, the Subscriber shall conclude a Subscriber agreement with Fina.

In the case of application certificates, the Agreement shall be signed by Legal Representative, i.e. the person authorised to represent the Business Entity.

In the case of certificates for electronic seal of Trusted List, the agreement shall be signed by the Authorised representative of the central state administration authority competent for economic affairs.

A certificate application may be submitted in Fina RA Network or in External RAs with whom Fina has concluded an agreement on providing some Subscriber registration services.

A certificate application may also be submitted in electronic form insofar as this shall be supported by Fina for individual certificate types.



4.1.2.1. Certificate Application Submission Process

An application for issuing personal certificates may be submitted by Natural persons - citizens.

An application for issuing business certificates that shall be issued to Associated persons and TDU certificates shall be submitted by Associated persons.

An application for issuing application certificates shall be submitted by the Custodian.

An application for issuing certificates for electronic seal of Trusted List shall be submitted by the Authorised representative of the central state administration authority competent for economic affairs.

An application for issuing administrative certificates shall be submitted by a Fina′ employee.

In the event that an application shall be submitted in electronic form, the application shall be signed using an advanced electronic signature.

Identification and authentication of applicants shall be carried out in the manner described in Section 3.2 of this Certificate Policy.

4.1.2.2. Obligations and Responsibilities in the Certificate Application Process

Subscribers shall conclude a Subscriber agreement with Fina by which they accept this Certificate Policy and the certification services terms and conditions.

Signing of the agreement by the Subscriber shall be carried out in the same way as signing of a certificate application, which shall be described in Section 4.1.2.1 of this Certificate Policy.

Prior to providing the certification services referred to within the scope of this Certificate Policy for each individual state administration authority, Fina shall conclude a business relationship with TDU by concluding a separate a Subscriber agreement.

In the certificate application process, applicants shall submit an accurately and entirely filled in and properly signed and sealed certificate application, while the documentation enclosed or submitted should be accurate and complete, and valid at the time of submission of the application.

The obligations and responsibilities of the Subscriber shall be listed in Section 9.6.3 of this Certificate Policy.

The obligations and responsibilities of the RA Network shall be listed under Section 9.6.2 of this Certificate Policy.

The obligations and responsibilities of Fina as a Trust Service Provider shall be listed in Section 9.6.1 of this Certificate Policy.



4.2. Certificate application processing

4.2.1. Performing identification and authentication functions

Identification and authentication of Natural persons and Business Entities referred to in the application shall be carried out in accordance with Chapter 3 of this Certificate Policy.

4.2.2. Approval or rejection of certificate applications

A RA Network Officer shall check the data contained in the documents provided by the applicant and shall confirm the accuracy and the integrity of the certificate application information.

The approval or rejection of certificate applications shall be entrusted to the RA Network to which the Applicant has submitted the application.

4.2.3. Time to process certificate applications

Under usual circumstances, the certificate application processing time shall be up to five business days from the receipt of the application by RA Network.

4.3. Certificate Issuance Fina CA shall issue certificates after all data verification processes have been carried out and after approval of 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.

4.3.1. CA actions during certificate issuance

During the certificate issuance process, Fina CA:

• shall check the validity of the electronic signature of the registration officer in the submitted approved application,

• shall generate a Subscriber key pair for certificates in accordance with Sections 6.1.1.3 and 6.1.1.4 of this Certificate Policy,

• shall create the requested certificate for a Subject's public key delivered in accordance with Section 6.1.3 of this Certificate Policy,

• shall ensure the certificate shall be accessible to the Signatory, Custodian or Authorised representative so that it may be downloaded,

• shall ensure the certificate shall be accessible on the Fina PKI repository.

4.3.2. Notification to the Subscriber by the CA of Issuance of certificate

The Signatory, Custodian or Authorised representative shall be notified about the possibility of acceptance of certificates by phone, e-mail or mail.



4.4. Certificate acceptance Acceptance of the certificate by a Signatory, Custodian or Authorised representative shall be a prerequisite for using the certificate.

By accepting the certificate, the Signatory, Custodian or Authorised representative, shall accept that all the data entered in the certificate shall be accurate and true at the moment of its acceptance, and that they shall not be misleading.

4.4.1. Conduct constituting certificate acceptance

The Signatory, Custodian or Authorised representative shall check certificate contents during or immediately upon acceptance of the certificate. Insofar as any part of a certificate contents shall be unacceptable, the Signatory, Custodian or Authorised representative shall immediately notify Fina about this and in doing so state the reasons for non-acceptance of the same.

It shall be deemed that the Signatory, Custodian or Authorised representative have accepted the certificate at the moment of its first use.

Insofar as the Signatory, Custodian or Authorised representative has not used the issued certificate within fifteen days of its acceptance, nor has refused to accept the certificate within this period, the certificate shall be deemed accepted.

4.4.2. Publication of the certificate by the CA

Insofar as the Signatory, Custodian or Authorised representative and the person authorised to represent a Business Entity have approved the publication, Fina CA shall make the certificate accessible on the Fina PKI repository.

Consent for the publication of certificates in the Fina PKI repository shall be given when concluding a Subscriber agreement.

4.4.3. Notification of certificate issuance by CA to other entities

It is implied that other parties have been notified of certificate issuance through its accessibility for download from the Fina PKI repository.

4.5. Key pair and certificate usage

4.5.1. Subscriber private key and certificate usage

In cases where the Subscriber has possession of and manages key pairs, then the Subscriber shall:

• upon generation of key pairs, use algorithms stipulated by the ETSI TS 119 312 [20] standardisation document and the length of the key in accordance with Section 6.1.5 of this Certificate Policy,



• use the private key and pertaining certificate solely for the purposes provided for in

this Certificate Policy, • use and keep the private key in a manner that shall prevent its unauthorised use, • use the Subject's key pair in accordance with the rules laid down in Section 1.4.1 of

this Certificate Policy, • protect the private key from theft, loss, change, compromise and unauthorised use, • 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 suspension or

revocation, • after the private key has been compromised, to immediately and permanently cease

using it.

4.5.2. Relying party public key and certificate usage

The Relying Party with the intention of relying on a certificate issued according to this Certificate Policy should:

• ensure the appropriate use and ban on the use of a public key and certificate, • check the validity period of all the certificates in the certificate chain, • check the revocation and suspension status.

4.6. Certificate renewal Each certificate renewal in Fina PKI shall imply certificate issuance with a new key pair to the same Subject data.

The procedure for certificate renewal shall be described in Section 4.7 of this Certificate Policy.

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 renewed certificate

See Section 4.7.5

4.6.6. Publication of the renewed certificate by the CA

See Section 4.7.6

4.6.7. Notification of certificate issuance by CA to other entities

See Section 4.7.7

4.7. Certificate re-key After carrying out identification and authentication of applicants for:

• routine certificate renewal with generation of a new key pair, • certificate issuance after expiry, • renewal after revocation, and • certificate recovery.

Fina shall issue a certificate whose parameters shall be 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 same Fina CA.

4.7.1. Circumstances for certificate re-key

Routine certificate renewal shall be carried out insofar as the Subscriber's certificate shall soon expire, and the Subscriber intends to continue using the service. A certificate renewal shall be carried out in this way if all of the following terms and conditions have been met:

• the validity of the certificate has not expired and the certificate shall expire in a period shorter than 45 days,

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

complete at the moment of submitting the certificate renewal application.

Certificate recovery shall be carried out in the event of cryptographic or QSCD device malfunction, deletion or destruction of the Subscriber's private key, or when the Subscriber, due to some other reason, shall not be able to use the private key connected with the public key in the certificate, and shall be conducted before the onset of deadlines for certificate renewal.

Certificate issuance after expiry shall be carried out insofar as the Subscriber's certificate has expired, and the Subscriber intends to continue to use the service. Certificate issuance after expiry shall not be considered renewal of an existent expired certificate.

A prerequisite for such certificate issuance shall be that the Subscriber data contained in the certificate was not modified.



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 same Subject who, in accordance with Section 4.1.1 of this Certificate Policy, may submit a certificate application.

4.7.3. Processing certificate re-keying requests

Fina shall support the following methods of processing applications for certificate renewal with a new key pair:

• processing applications submitted in the RA Network, • processing applications submitted online.

In the event of an application submitted in the RA Network, the identification and authentication of Natural persons and Business Entities referred to in the application shall be carried out in accordance with Section 3.3.1.1 of this Certificate Policy. The RA Network Officer shall check the details in the application and shall confirm the accuracy and integrity of information in the application. The approval or rejection of applications shall be carried out in the RA Network office to which the application was submitted.

In the event of an application submitted online, the identification and authentication of the applicant shall be carried out in accordance with Section 3.3.1.2 of this Certificate Policy. The accuracy and integrity of the information in the application shall be checked.

Verification of data in the application shall be 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 valid legislation.

After verifying the authenticity and validity of an application, Fina CA shall issue a certificate in accordance with Section 4.3.1 of this Certificate Policy.


Fina shall notify the Signatory, Custodian or Authorised representative about the upcoming certificate expiry, and shall invite them to renew the certificate and carry out generation of a new key pair.

Notification of the Signatory, Custodian or Authorised representative about the certificate renewal shall be done in accordance with Section 4.3.2 of this Certificate Policy.

4.7.5. Conduct constituting acceptance of a re-keyed certificate

Conduct constituting acceptance of a renewed certificate issued in accordance with Section 4.7.1 shall be carried out in accordance with Section 4.4.1 of this Certificate Policy.



4.7.6. Publication of the re-keyed certificate by the CA

Publication of a renewed certificate issued in accordance with Section 4.7.1 shall be carried out in accordance with Section 4.4.2 of this Certificate Policy.

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

Notification of other parties about a renewed certificate issued in accordance with Section 4.7.1 shall be carried out in accordance with Section 4.4.3 of this Certificate Policy.

4.8. Certificate modification Signatories or Business Entities shall be obliged to notify Fina about the modification of data contained in the certificate within seven days and request certificate data modification.

Fina shall carry out data modification exclusively with respect to a certificate that has not been revoked, suspended or which has not expired.

4.8.1. Circumstance for certificate modification

Reasons for modifications of personal, business and Administrative certificates, and certificates for TDU, may be modifications to data that shall refer to the Subject:

• Signatory's name or surname, • Business Entity name, • TDU Sub-organization unit name, • data on the place of residence of the Natural person or the registered office of the

Business Entity, • e-mail addresses of the Subject for certificates containing this content in the Subject

alternative name extension of the certificate.

Reasons for modifications within an application certificate may be modifications of data that refer to the Subject:

• application name, • name or registered office location of the Business Entity, • e-mail addresses.

Reasons for modifications within the certificate for electronic seal of Trusted List may be modifications of data that refer to the Subject:

• name with which the Subject usually presents itself, • name or locality in which the registered office of the central state administration

authority is located.

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



4.8.2. Who may request certificate modification

An application for modifications to a certificate after its expiry, may be submitted by the same Subject who, in accordance with Section 4.1.1 of this Certificate Policy, may submit a certificate application.

4.8.3. Processing certificate modification requests

A request for modification to data shall be submitted together to the RA Network. Identification and authentication of applicants shall be carried out in accordance with the procedure for initial authentication referred to in Section 3.2 of this Certificate Policy. Processing of applications and certificate issuance shall be carried out in accordance with Section 4.2, 4.3 and 4.4 of this Certificate Policy.

An application for modification of e-mail addresses and for modifications to data referring to the Subject may be submitted online using an advanced electronic signature. After verifying the authenticity and validity of an application, Fina CA shall issue a certificate in accordance with Section 4.3.1 of this Certificate Policy.


When issuing certificates in the process of certificate modification, notification of Subscribers shall be carried out according to Section 4.3.2 of this Certificate Policy.

4.8.5. Conduct constituting acceptance of the modified certificate

Modified certificates shall be accepted in accordance with Section 4.4.1 of this Certificate Policy.

4.8.6. Publication of the modified certificate by the CA

Publication of modified certificates shall be carried out as described in Section 4.4.2 of this Certificate Policy.

4.8.7. Notification of certificate issuance by the CA to other entities

Other parties shall be notified about modified certificate issuance as described in Section 4.4.3 of this Certificate Policy.

4.9. Certificate revocation and suspension

4.9.1. Circumstances for revocation

Fina shall revoke a certificate:

• if some of the information in the certificate shall become inaccurate, • in a case of private key compromise or if there is a reasonable suspicion about

private key being compromised,



• if the private key or activation data are no longer in the sole possession of the

Signatory, or the Business Entity, • in event of loss or permanent unavailability of the private key, • in the event of termination of the relationship between the Signatory and Business

Entity on the basis of which the certificate was issued, • if the certificate has not been issued in accordance with the application, • if the certificate was not issued in accordance with this Certificate Policy or

CPSNQC-eIDAS document [32], • in the event of termination of the Subscriber Agreement by the Subscriber, • in the event of an official notification that the certificate has been used for illegal

purposes, • if Fina assesses that the certificate with its technical characteristics, profile or content

shall no longer provide the appropriate level of trust to Relying parties, • in cases when this shall be required by law or other regulations.

Fina my revoke a certificate if a Subscriber, Signatory or Authorised representative shall not execute its obligations in accordance with the Policy and signed agreements.

4.9.2. Who can request revocation

A request for revocation of a corresponding personal certificate for electronic signature shall be submitted by the Signatory.

A request for revocation of business and TDU certificates shall be submitted by a Signatory or Legal Representative, i.e. person authorised for representation of a Business Entity.

A request for revocation of application certificates shall be submitted by a Custodian or Legal Representative, i.e. person authorised for representation of a Business Entity.

A request for revocation of certificates for electronic seal of Trusted List shall be submitted by the Authorised representative of the central state administration authority competent for economic affairs.

A request for revocation of an administrative certificate shall be submitted by a Signatory or authorised person in Fina.

The RA Network may file a request for revocation of a certificate.

Fina may also revoke a certificate based on an authenticated notification by a third party or based on an authenticated official notification by a competent body.

4.9.3. Procedure for revocation request

Immediately upon the occurrence of any reason for revocation listed in Section 4.9.1 of this Certificate Policy, the written certificate revocation request shall be filled in accurately and entirely, as well as signed and submitted as soon as possible in one of the following ways:



• by personal delivery to a RA Network office during office hours, • by mail or courier to a RA Network office address, • electronic delivery of the revocation application to the e-mail address.

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.

In the event that the request for revocation of a certificate shall be based on a report from a third party, Fina shall verify the merits of this request before revoking the certificate.

On the basis of an accurately filled out and signed revocation request, Fina shall revoke a certificate and notify the Signatory, Custodian and Authorised representative thereof, and insofar as this shall be applicable, the Business Entity with which the Signatory is associated.

If the certificate revocation request is submitted by telephone, Fina shall authenticate the person requesting the revocation through his knowledge of password entered in Certificate application form and shall revoke the certificate and notify the Signatory, or the Authorised Representative thereof, and, if applicable, the Business Entity with which the Signatory is associated.

After revoking a certificate, the Fina CA who issued the revoked certificate shall issue and publish a CRL, while information about the revocation status of the certificate shall also become accessible on the OCSP service.

4.9.4. Revocation request grace period

The applicants of certificate revocation requests referred to in Section 4.9.2 of this Certificate Policy shall submit the certificate revocation request as soon as reasonably possible from the occurrence of the reasons for revocation listed in Section 4.9.1.

4.9.5. Time within which the CA must process a revocation request

Fina CA shall revoke a certificate as soon as reasonably possible, at the latest within 24 hours from receipt of an appropriate certificate revocation request, or shall suspend the certificate.

Immediately after certificate revocation, Fina CA shall promptly update the data base of the certificate and shall issue a new CRL.

4.9.6. Revocation checking requirement for Relying parties

Reliance on a revoked or suspended certificate may cause personal or business damage to the Relying Party. For this reason, before achieving reliance in the certificate, Relying parties shall verify the status of the certificate with the aim of establishing its revocation or suspension, and in accordance with Sections 4.5.2, 4.9.9 and 4.9.10 of this Certificate Policy.



If the Relying Party shall not be able to acquire information about a certificate status at a given moment, the Relying Party shall not rely on such a certificate.

4.9.7. CRL issuance frequency

Fina RDC 2015 shall issue and sign a Fina RDC 2015 CRL, while Fina RDC-TDU 2015 shall issue and sign a Fina RDC-TDU 2015 CRL. Revocation status information shall include information on the status of certificates at least until the certificate expires. These lists shall be published immediately upon revocation, suspension or reactivation of certificates, and each six hours from the previous issuance of CRL.

4.9.8. Maximum latency for CRLs

Immediately after certificate revocation, Fina CA shall promptly update the data base of the certificate and shall issue a new CRL. Maximum latency for CRL from the moment of its issuance to the moment of its publication in regular circumstances shall amount to two minutes.

4.9.9. On-line revocation/status checking availability

Fina CAs support online status check of issued certificates revocation via Fina OCSP service whose operation shall be aligned with recommendation IETF RFC 6960 [28].

Information about the certificate revocation status via Fina’s OCSP service shall be available in real time.

The address of the Fina OCSP service is http://ocsp.fina.hr, and shall be entered in the extension Authority Information Access of each certificate issued by Fina CAs.

CRL shall be available primarily through HTTP Internet address on the server of the corresponding repository, and secondarily through the LDAP Directory, as described in Section 4.10.1 of this Certificate Policy. Data about access points for retrieving CRL shall be contained in each issued certificate.

4.9.10. On-line revocation checking requirements

In order to use Fina OCSP service, the Relying Parties shall have access to the Internet and use applications that can use OCSP service referred to in Section 4.10.1 hereof.

For online acceptance of CRL, the Relying parties must have access to the Internet and use of applications or solutions that enable CRL download from Internet addresses, and to protocols referred to in Section 4.10.1 of this Certificate Policy.

4.9.11. Other forms of revocation advertisements available

No stipulations.




4.9.12. Special requirements re key compromise

No stipulations.

4.9.13. Circumstances for suspension

Fina shall conduct certificate suspensions:

• if the Signatory, Custodian or Authorised representative, due to the suspicion listed in Section 4.9.1, shall submit a certificate suspension application,

• temporarily until the revocation requested due to the reasons referred to in Section 4.9.1, and while the RA Network runs all necessary certificate revocation checks or until the revocation documentation shall be delivered to RA Network,

• in the event of default by Subscriber regarding the payment of services provided.

4.9.14. Who can request suspension

An application for suspension of a corresponding personal certificate for electronic signature shall be submitted by the Signatory.

An application for suspension of business or TDU certificates shall be submitted by a Signatory or Legal Representative, i.e. person authorised for representation of a Business Entity.

An application for suspension of application certificates shall be submitted by a Custodian or Legal Representative, i.e. person authorised for representation of a Business Entity.

The application for suspension of certificates for electronic seal of Trusted List shall be submitted by the Authorised representative of the central state administration authority competent for economic affairs.

The RA Network may file an application for suspension of a certificate.

Fina may also suspend a certificate based on an authenticated notification by a third party or based on an authenticated official notification by a competent body.

An application for reactivation of a corresponding personal certificate shall be submitted by the Signatory.

An application for reactivation of business or TDU certificates shall be submitted by a Signatory or Legal Representative, i.e. person authorised for representation of a Business Entity.

The application for reactivation of certificates for electronic seal of Trusted List shall be submitted by the Authorised representative of the central state administration authority competent for economic affairs.



4.9.15. Procedure for suspension and reactivation request

4.9.15.1. Procedure for suspension request

Immediately upon occurrence of any reason for suspension listed in Section 4.9.13 of this Certificate Policy, the certificate suspension request shall be filled in accurately and entirely, as well as signed and submitted as soon as possible in one of the following ways:

• by personal delivery to a RA Network office during office hours, • by mail or courier to a RA Network office address, • by telefax, • electronic delivery of the revocation application to the e-mail address.

Certificate suspension 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.

In the event that the request for suspension of a certificate shall be based on a report from a third party, Fina shall verify the merits of this application before suspending the certificate.

On the basis of an accurately filled out and signed suspension request, that is, by verifying the knowledge of password entered on Certificate application form of Applicant in the case of a telephone application, Fina shall suspend a certificate and notify the Signatory, Custodian and Authorised representative thereof, and insofar as this shall be applicable, the Business Entity or TDU.

After suspending a certificate, the Fina CA who issued the suspended certificate shall issue and publish a CRL, while information about the suspended status of the certificate shall also become accessible on the OCSP service.

4.9.15.2. Procedure for reactivation request

The request for reactivation of certificates should be filled in accurately and entirely, signed and submitted in one of the following ways:

• by personal delivery to a RA Network office during office hours, • by mail or courier to a RA Network office address, • electronic delivery of the reactivation application to the e-mail address.

On the basis of an accurately filled out and signed reactivation application, Fina shall reactivate a certificate and notify the Signatory, Custodian and Authorised representative thereof, and insofar as this shall be applicable, the Business Entity or TDU.

After reactivating a certificate, the Fina CA who issued the reactivated certificate shall issue and publish a CRL, while current information about the certificate status shall also become accessible on the OCSP service.



4.9.16. Limits on suspension period

The maximum certificate suspension period shall be 60 days. After the expiry of such period, Fina CA shall revoke the certificate and publish the CRL.

4.10. Certificate status services

4.10.1. Operational characteristics

Fina shall give information about the revocation or suspension status of a certificate through providing OCSP service or publication of CRL.

Revocation status information shall include information on the status of certificates at least until the certificate expires.

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

The address of the Fina OCSP service is http://ocsp.fina.hr, and it shall be entered into the Authority Information Access extension of each certificate issued by Fina CAs.

CRL for certificates issued by Fina CAs shall be published on the Internet server and in the public directory of the repository of a specific Fina CA. Consolidated CRL shall be published on the Internet server, and consolidated and segmented CRL shall be published in the public directory.

Addresses of CRL publication shall be contained in the CRLDistributionPoints extension in each issued certificate.

If a Relying Party's application supports operation with a segmented CRL, the public directory application shall retrieve a certain segment of the CRL.

If a Relying Party’s application does not support operation with a segmented CRL, CRL shall be retrieved in the following order:

1. application from the Internet server shall retrieve a consolidated CRL,

2. if the internet server is not accessible, the consolidated CRL application retrieves from the public LDAP directory.

4.10.2. Service availability

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




4.10.3. Optional features

No stipulations.

4.11. End of subscription If a Subscriber shall terminate the agreement before the expiry of a certificate, Fina CA shall revoke all certificates associated with this Agreement.

4.12. Key escrow and recovery Key escrow of Subscribers private keys of qualified certificates is not allowed.



5. FACILITY MANAGEMENT AND OPERATIONAL CONTROLS

Fina shall ensure adequate protection of assets used to provide the service of non-qualified certificate issuance and for this purpose shall keep a complete list of these assets with the corresponding classification which is aligned with the risk assessment.

Physical protection measures, procedures implemented by Fina within the context of system protection for certificate issuance (hereinafter referred to as: the certification system), as well as verification procedures of this system, management and operational procedures in Fina PKI shall be of an internal nature and the details thereof shall not be publicly disclosed.

5.1. Physical controls As a qualified certificate issuance service provider, Fina shall implement physical protection measures for the certification system with the aim of minimising risks related to physical protection and in accordance with Fina's business policy and valid legislation.

5.1.1. Site location and construction

Fina's primary certification production system shall be situated inside Fina's building, in separate premises envisaged for this purpose, subject to implementation of multiple levels of physical and technical protection that prevent unauthorised physical access to the system and data, and with this shall prevent the system and service from being compromised. Physical protection shall be based on the concept of using security zones, and the level of protection shall increase upon passing into the next zone. Physical protection against breach shall be achieved by security perimeters that shall separate zones set around the certification system in which creation operations and the revocation of non-qualified certificates shall be carried out.

The purpose of Fina's secondary certification system shall be to take over the functions of the primary certification system in the event that the primary production system ceases operations and up until its recovery and the restoration of services. The secondary certification system shall be situated at a separate, remote Fina site and shall comply with equal or higher security requirements compared to the primary system.

Secure premises and sub-premises in which the components of Fina's certification systems shall be located at the primary and secondary sites shall hereinafter be referred to as: the Fina PKI protected premises.

5.1.2. Physical access

Physical access to the certification system in Fina PKI protected premises and pertaining sub-premises within these premises shall be possible through dual control of passage by Fina PKI authorised persons, and in accordance with their roles and authority.

Persons without authority for physical access to the certification system, shall only be permitted access if they are accompanied by authorised persons and in accordance with Fina internal procedures.



Records shall be kept about each access to the certification systems.

Physical access to registered Subscriber data collected by the RA Network shall be granted only to Fina PKI authorised personnel and authorised Fina RA Network employees, or External RA authorised employees, who collect, store, use and delete personal data of Natural persons in accordance with adequate legislation on personal data protection.

5.1.3. Power and air conditioning

The devices and premises in which Fina CAs, Fina RA system, repository and technical protection systems are located shall be continuously supplied with electricity and air conditioning sized to ensure appropriate operational conditions even in the event of external power supply interruptions.

5.1.4. Water exposures

The locations at which Fina CAs, Fina RA systems and repository are located, shall be protected against floods.

5.1.5. Fire prevention and protection

Fina CAs, Fina RA system and repository shall be protected with a system for detection of fire and an automatic fire extinguishing system in accordance with valid legislation.

5.1.6. Media storage

Media containing archive and backup of Fina PKI data in electronic form, copies of repository content and backup of software, shall be stored in two separate protected locations with established fire prevention and protection and are secured against floods. This media shall also be protected against damage, theft and unauthorised access.

5.1.7. Waste disposal

Devices and media containing confidential information in electronic form, no longer required, shall be securely destroyed so that confidential information shall no longer be readable or renewable. The destruction of these devices and media shall be carried out under the supervision of authorised persons in Fina PKI.

Paper documents and material containing confidential information shall be securely destroyed before waste disposal.

5.1.8. Off-Site backup

Backup of Fina CA and RA systems, archive or backup data, repository content backup and software backup shall be stored at a secondary certification system location, which shall be separate from the primary certification production system. The level of physical protection measures for this backup shall be equal or greater level than the one applied to their originals.



5.2. Procedural controls

5.2.1. Trusted roles

Information and communication system management tasks, certificate life cycle management tasks, administering and implementation of security procedures, and Fina PKI operation supervision tasks shall be carried out within separate Fina organizational units.

Tasks, obligations and responsibilities of employees shall be divided according to appropriate trusted roles. Trusted roles shall comprise the basis of trust in Fina PKI and shall be assigned to authorised employees from competent Fina organizational units. Each trusted role shall be documented with a clearly defined description of tasks and responsibilities.

Trusted roles shall include the roles of Security Officer, System Administrator, System Operator, Registration Officer, Revocation Officer and System Auditor.

5.2.2. Number of persons required per task

Fina PKI tasks shall be performed exclusively by authorised persons. Fina shall have a sufficient number of full-time employees with knowledge, experience and qualifications required within Fina PKI to provide services within the scope of this Certificate Policy.

Access and tasks in Fina PKI protected premises shall only be carried out in the presence of at least two persons with trusted roles who have permission to access this system.

The participation of a stipulated number of persons with specific trusted roles shall be required to carry out individual security sensitive tasks in Fina PKI protected premises.

5.2.3. Identification and authentication for each role

Upon logging on to critical applications and services within Fina PKI, identification and authentication of the person accessing the application or service shall be carried out. Identification and authentication of persons shall be carried out using the appropriate authentication method. Access and use of applications and services within Fina PKI shall only be enabled for authorised persons in accordance with the trusted role they perform. While using critical applications and services, the activities of persons logged in shall be properly noted, stored and kept.

5.2.4. Roles requiring separation of duties

Due to security requirements for non-qualified certificate issuance, the following duties should be separated:

• the person assigned the trusted role of Security Officer or Registration Officer shall not be assigned the trusted role of System Auditor,

• the person assigned the trusted role of System Administrator shall not be assigned the trusted role of Security Officer or System Auditor.



5.3. Personnel controls

5.3.1. Qualifications, experience, and clearance requirements

Prior to starting work at jobs in Fina PKI, candidates must possess the appropriate expert knowledge, experience, qualifications and education for work with cryptographic technologies, protection of computer systems, IT security and protection of personal data in the domain of his/her scope of work within the framework of Fina PKI operations.

Employees working at Fina PKI may not be employed nor have any business relationship with other certification service providers.

5.3.2. Background check procedures

Prior to starting work at jobs in Fina PKI, Fina shall carryout adequate candidate checks in order to assess their expertise, ability and reliability in accordance with the needs of Fina PKI tasks.

5.3.3. Training requirements

Employees carrying out tasks within Fina PKI shall be provided with education and training in accordance with their trusted roles.

5.3.4. Retraining frequency and requirements

Awareness about IT security shall be conducted once annually for all Fina PKI employees.

Education employees with trusted roles in Fina PKI shall be carried out once annually with the aim of acquiring new knowledge and skills training.

Renewal of knowledge of Fina RA Network employees, given the jobs they perform, shall be conducted regularly, at least once every two years.

5.3.5. Job rotation frequency and sequence

No stipulations.

5.3.6. Sanctions for unauthorised actions

Non-abidance of stipulated measures for authorised persons when working in Fina PKI shall be subject to breach of work obligations, while possible penalties shall be determined through disciplinary proceedings.

In the event of unauthorised actions by external contractors, the provisions defined in the agreement with the external contractors shall apply.



5.3.7. Independent contractor requirements

For external contractors who carryout part of the services within the scope of non-qualified certificate issuance services for Fina, the same requirements as those that apply to internal employees shall apply when working in Fina PKI.

Requirements for suppliers of goods and services for Fina PKI shall be regulated by internal documents about work with suppliers. Access by external contractors to IT assets in Fina PKI shall be approved exclusively pursuant to an agreement for only that IT asset that shall be the subject of the agreement and only for the activity listed in the agreement.

5.3.8. Documentation supplied to personnel

The documentation required for the implementation of their work tasks according to the trusted role assigned and pertaining authorisations shall be supplied to each employee.

5.4. Audit logging procedures

5.4.1. Types of events recorded

Records about all events in Fina PKI related to the following shall be recorded in audit logs:

• management of life cycles of CA keys of Fina CAs, • registration of Natural persons, Business Entities and systems or applications, • preparation and issuing of secure cryptographic or QSCD devices on which non-

qualified certificates are also issued, • key life cycles and key management, • life cycles of certificates issued by Fina CAs, • request for revocation, suspension and reactivation of certificates and

correspondingly conducted activities.

Security events in Fina PKI related to modifications of security policy, physical and technical protection of Fina PKI premises, initiation and stoppage of work systems, system errors and hardware malfunctions, firewall and router activities, and attempts to access the system shall be recorded in audit logs.

5.4.2. Frequency of processing log

Audit logs in Fina PKI shall be regularly inspected on a daily basis. Audit logs shall also be inspected for the purpose of monitoring and determining malicious activity in the system. Fina shall use automatic mechanisms for warnings and alerts about possible critical security events. Such notifications shall be sent to authorised persons in Fina PKI. Actions undertaken based on audit log collection shall be documented.

5.4.3. Retention period for audit log

The audit logs with records referred to in Section 5.4.1 shall be kept for at least 10 years from the expiry of the certificate to which the record refers.



5.4.4. Protection of audit log

Audit logs in Fina PKI shall be protected throughout the entire time they are kept. Protection of audit logs encompasses the protection of records against their unauthorised reading and disclosure, and protection of the integrity of the log.

Audit logs protected in such a way shall be available only at the request of authorised persons, particularly for the purpose of providing evidence regarding a certificate in court proceedings.

5.4.5. Audit log backup procedures

Fina PKI audit logs shall be daily stored and archived in two copies at physically separate locations.

Audit log backups at a secondary location shall be protected at the same or higher level of protection compared to audit logs at the primary location (see Section 5.4.4.).

5.4.6. Audit collection system (internal vs. external)

Depending on data type, audit logs shall be collected automatically or shall be collected by an authorised person.

Audit logs created in the Fina PKI and Fina RA Network shall be collected internally.

The collection of audit logs created in external RAs shall be regulated by an agreement.

5.4.7. Notification to event-causing subject

In the event that a log about a significant event in the work of Fina PKI has been observed, which is connected to a specific participant, Fina shall reserve the right to determine about whether to notify the participant who caused the event.

5.4.8. Vulnerability assessments

Fina shall carryout regular risk assessments of IT assets, vulnerability assessments for recognised public and private addresses and penetration testing.

Risk assessment of IT assets shall be conducted once annually. Fina PKI shall carryout vulnerability assessments of the system for recognised public and private addresses quarterly. Penetration tests shall be carried out once annually.

5.5. Records archival

5.5.1. Types of records archived

Fina PKI shall archive the below specified data which, depending on the type, may come in electronic and/or paper form:



• Certificate Policies, • Certification Practice Statements, • Certification Services Terms and Conditions, • agreements connected to the provision of certification services, • data and pertaining documentation collected during the process of registration of

natural persons and Business Entities, • data and documentation related to secure cryptographic or QSCD devices, • certificates and data related to the life cycle of individual certificates, • records of revoked and suspended certificates, data about revocation, suspension

and reactivation of certificates and pertaining documentation, • the audit logs referred to in Section 5.4.1 of this Certificate Policy, • other Fina internal documents.

5.5.2. Retention period for archive

All archived data and documentation shall be kept by Fina for at least 10 years from the expiry of certificates to which they refer.

5.5.3. Protection of archive

Archived data and documentation shall be protected using protection level mechanisms and procedures ensuring archive confidentiality and integrity. The archive shall be protected from unauthorised review, modification, and deletion of data.

The same level of protection shall also be ensured for archiving data and documentation collected in External RAs.

Archived records protected in such a manner shall be available only at the request of authorised persons, particularly for the purpose of providing evidence about an issued certificate for the needs of court proceedings.

5.5.4. Archive backup procedures

Backup of archived data in electronic form shall be created in Fina PKI's protected premises and stored in a secure manner at another location separate from the primary production certification system, in accordance with Section 5.1.8 of this Certificate Policy.

5.5.5. Requirements for time-stamping of records

No stipulations.

5.5.6. Archive collection system (internal or external)

Records to be archived shall be collected in a manner that depends on the type of record.

Records to be archived created in the Fina PKI and Fina RA Network shall be collected and archived internally.



The collection of records created in the External RAs to be archived shall be regulated with an agreement.

5.5.7. Procedures to obtain and verify archive information

Only persons authorised to access archive data shall have access to the archived data.

Verification of archive data shall be done by verifying its integrity.

5.6. Key changeover Fina shall ensure that Fina CA continually provides trust services with its valid key pair and corresponding CA certificate. For this reason Fina CA shall generate a new CA key pair sufficiently before the expiry of the CA certificate. Furthermore, Fina CA shall generate a new CA key pair sufficiently earlier, even in the case when this change shall be required due to the level of security of cryptographic algorithms of the private CA key in use. In both cases, for a new public CA key, Fina Root CA shall issue a CA certificate.

Fina CA shall notify the participants of Fina PKI about changes to its public key and new CA certificate in a timely manner.

The new corresponding public key shall be accessible to Fina PKI participants in the same way as the previous Fina CA public key, and in accordance with the description in Section 2.2 of this Certificate Policy.

5.7. Compromise and disaster recovery

5.7.1. Incident and compromise handling procedures

The business continuity plan for Fina PKI shall regulate the procedures in the event of the occurrence of incidents or system compromise, which encompass procedures for system recovery and the establishment of security terms and conditions for providing certificate issuance services.

The business continuity plan shall be revised once annually.

5.7.2. Computing resources, software and/or data are corrupted

Fina's certification system was founded on reliable hardware and software components, while critical operations of the system shall be supported by redundant components.

Functionality, proper operation and timely elimination of damaged components of the certification system shall be secured through support and maintenance agreements with equipment suppliers.

The business continuity plan for Fina PKI, shall regulate the procedure for recovery of the certification system in the event of malfunctions or damage to equipment and network resources and the return of data.



5.7.3. Entity private key compromise procedures

In the event that the private key of Fina CA shall be compromised, the corresponding CA certificate shall be revoked by Fina Root CA.

Fina shall notify the following participants of Fina PKI about the revocation of Fina CA certificates:

• Fina RA Network and External RAs, • Subscribers, • Relying parties.

After determining and eliminating the cause responsible for CA key compromise, Fina shall if appropriate, undertake measures to prevent the recurrence of such an event. Fina CA whose certificate has been revoked shall generate a new CA key pair. Fina Root CA shall issue a new CA certificate for a new public CA key.

Fina CA shall, by using the new private CA key, issue certificates to existing registered Subjects, and all subsequent information about revocation of certificates shall be signed using the new key. The new CA certificate shall be accessible to Fina PKI participants in the same way as the previous CA certificate, and in accordance with the description in Section 2.2 of this Certificate Policy.

If the cryptographic algorithms and parameters used cease to provide the required security and protection, Fina will, if possible, notify in due time:

• Fina RA network and external RAs, • Subscribers, • Relying parties.

Fina will consider using other appropriate recommended secure cryptographic algorithms and, if possible, make a decision about using another algorithm. Fina will develop specific plans and procedures that will necessarily include the implementation of the revocation of all certificates that are affected by cryptographic algorithms and parameters whose security is compromised. About Fina's plans and deadlines will inform Subscribers and Relying parties.

5.7.4. Business continuity capabilities after a disaster

The procedures for continued operations after a disaster shall be determined in the Business continuity plan. Depending on the type of disaster, Fina shall continue providing non-qualified certificate issuance services at its primary production certification system or the provision of services shall continue at its secondary certification system referred to in section 5.1.1. of this Certificate Policy until the recovery of its primary production system.

5.8. CA or RA termination In case of External RA operation termination, its operations may be taken over by Fina RA Network. More detailed provisions related to External RA operation termination shall be determined by means of an agreement.



About the planned cessation of providing non-qualified certificate issuance services, Fina shall:

• notify all service Subscribers, Relying parties and central state administration authority competent for economic affairs at least three months before the planned cessation of providing non-qualified certificate issuance services,

• invest all possible effort to continue providing non-qualified certificate issuance services at another Trust Service Provider and shall forward to this service provider all documentation collected in the Subscriber registration procedure, as well as all documentation about issued certificates,

• revoke all issued non-qualified certificates, • revoke the CA certificates and destroy their related private keys of those Fina CAs

that cease its operations.

In the event of cessation of providing non-qualified certificate issuance services, Fina shall archive, protect and keep records according to the provisions referred to in Section 5.5 of this Certificate Policy, so that the records are accessible for providing evidence at court, administrative and other proceedings in accordance with the valid provisions of legislation, or Fina shall contract such archiving, protection and keeping of records by another Business Entity.



6. TECHNICAL SECURITY CONTROLS

This Chapter shall describe protection measures undertaken with the aim of achieving the required level of security for cryptographic key, activation data, critical security parameters, key management and other technical security measures for Fina CAs, for Fina OCSP services and for issuing Subscriber certificates.

6.1. Key pair generation and Installation

6.1.1. Key pair generation

Fina shall conduct generation of Fina CA key pairs using algorithms for key generation in compliance with the standardised document ETSI TS 119 312 [20].

6.1.1.1. Fina CA Key Pair Generation

The procedure for generation of Fina CA key pairs shall be carried out through a formal Fina CA key pair generation ceremony for subordinated Fina CAs.

The Fina CA key pair generation ceremony shall be carried out following a key generation protocol documenting the steps performed during a ceremony. The protocol for key generation shall be in accordance with technical security measures according to the standard ETSI EN 319 411-1 [15] and with the requirements of CA/Browser Forum BRG [30].

Key pairs for Fina CAs shall be generated, under minimal dual control of authorised persons with trusted roles in Fina PKI, in HSM modules that meet the requirements referred to in Section 6.2.1 of this Certificate Policy.

Fina CA shall be located in Fina PKI protected premises referred to in Section 5.1.1 of this Certificate Policy during and after the key pair generation ceremony, and access to Fina CA shall be allowed only to Fina PKI authorised persons with trusted roles exercising minimal dual control.

The Fina CA key pair generation ceremony procedure shall be videotaped or the conducted procedure shall be witnessed by a Qualified auditor.

A transcript of the carried out CA keys generation shall be recorded together with the attached audit logs.

Fina shall possess the Qualified auditor's report witnessing that the Fina CA key pair generation procedure has been carried out in compliance with the protocol and requirements for key generation.

6.1.1.2. RA Key Pair Generation

Key pairs for Fina RA Network authorised persons are generated in secure cryptographic devices that comply with the requirements referred to in section 6.2.1. of this



Certificate Policy. Key pairs are generated by Registration officers in their LRA offices, and they may also be generated by Registration officers in the Fina’s Central RA.

6.1.1.3. Subscriber key pair generation for NCP+ certificates

a) Subscriber key pair generation on QSCD or secure cryptographic device

Key pairs for the following types of certificates issued by Fina RDC 2015 CA shall be generated on QSCD or secure cryptographic devices:

• Personal authentication certificate (NCP+), • Business authentication certificate (NCP+), • Application Certificate Level 2 (NCP+), • Certificate for e-seal of Trusted List (NCP+), • Administrative Certificate (NCP+).

Key pairs for TDU authentication certificate (NCP+) issued by Fina RDC-TDU 2015 CA shall be generated on QSCD or secure cryptographic devices:

The QSCD and secure cryptographic device on which keys shall be generated, shall comply with the requirements referred to in section 6.2.1 of this Certificate Policy.

To carry out generation of Subscriber key pair for this certificates the associated Signatory or Custodian, and Registration officer in Fina LRA and Registration officer in the Fina’s Central RA shall be authorised. These authorised persons shall generate Subscriber key pair at their locations.

The generation of Subscriber key pair for the Certificate for e-seal of Trusted List (NCP+) shall be carried out by Registration officers in Fina LRA and Registration officers in the Fina‘s Central RA.

The procedure for generation of key pair for these certificates shall be managed by Fina.

The key pair generation procedure for the Business authentication certificate (NCP+) may also be managed by an externally contracted Trust Service Provider who shall also carryout registration services for Fina.

The key generation procedure shall also include checking whether a key pair generation shall be carried out in QSCD or secure cryptographic devices.

b) Subscriber key pair generation in HSM module

In the HSM module, key pairs shall be generated for Application certificate level 3 (NCP+) type of certificate issued by Fina RDC 2015 CA:

The HSM module in which keys shall be generated shall comply with the requirements referred to in section 6.2.1 of this Certificate Policy.



To carry out generation of Subscriber key pairs for these certificates, the associated Custodians who carry out generation of Subscriber key pairs at their locations are authorised.

6.1.1.4. Subscriber key pair generation for NCP certificates and LCP certificates

Key pairs for the following certificate types issued by Fina RDC 2015 CA shall be generated by software modules:

• Personal soft certificate (NCP), • Business soft certificate (NCP), • Business Soft Certificate (LCP), • Application Certificate Level 1 (NCP), • Application Certificate Level 2 (NCP).

Subscriber key pair generation for these certificates shall be carried out by Fina in their PKI protected premises referred to in Section 5.1.1 of this Certificate Policy. The Custodian shall also be authorised for generation of Subscriber key pairs of the certificate types Application certificate level 1 (NCP) and Application certificate level 2 (NCP).

In the event that the Custodian carries out key pair generation, the generation shall be carried out at the location of the Business Entity. Generating a key pair for the certificate application level 2 (NCP) is carried out in a controlled environment at the location of a business entity. Private keys shall be protected in software protected token, according to Section 6.2.1. of this Certificate Policy.

6.1.2. Private key delivery to subscriber

If the Registration officer generates its key pair, it shall be deemed that he/she already possesses a private key.

If the Signatory, Custodian or Authorised representative at their location generate a private key on a QSCD device, secure cryptographic device or software module, it shall be deemed that the Signatory, Custodian or Authorised representative shall already be in possession of the private key.

If the Registration officer in Fina LRA or Registration officer in the Fina’s Central RA at his/her location generate a private key for a Signatory, Custodian or Authorised representative on a QSCD or secure cryptographic device, then Fina shall ensure the secure delivery of the private key in a QSCD or secure cryptographic device to the Signatory, Custodian or Authorised representative.

If Fina generates a private key in a software module, then Fina shall ensure the secure online delivery of a private key and corresponding certificate in software protected token to the Signatory or Custodian.



6.1.3. Public key delivery to CA

The Subscriber public key shall be delivered for certification in Fina CA in a way that shall ensure verification of the integrity and authenticity of the public key, and in a way that securely connects the confirmed identity of the Subject and corresponding public key being delivered.

Delivery of a public key shall be carried out through a secure electronic communication channel after successful authentication of the person authorised for carrying out Subscriber key pair generation. Persons authorised for Subscriber key pair generation for individual types of Subscriber certificates shall be listed in Section 6.1.1 of this Certificate Policy.

If a Subscriber key pair shall not be generated by Fina, the certificate application process shall include checking whether a Signatory or Custodian possesses or controls a private key connected with a public key, which shall be forwarded in a secure way to Fina for certificate creation.

It shall be ensured that the public key being delivered for certification shall be from the key pair generated in a QSCD or secure cryptographic device for the certificates listed in Section 6.1.1.3 a) of this Certificate Policy, for the certificate application process.

6.1.4. CA public key delivery to Relying parties

Public keys of Fina CAs shall be accessible to Relying parties in Fina CA certificates issued by Fina Root CA. Hash of the Fina Root CA certificate shall be delivered through trusted channel.

6.1.5. Key sizes

The key sizes in Fina PKI shall be as follows:

• Fina Root CA shall use sha256WithRSA algorithm with 4096-bit long keys, • Subordinated Fina CAs (Fina RDC 2015 and Fina RDC-TDU 2015) shall use

sha256WithRSA algorithm with 4096-bit long key, • Fina OCSP service shall use 2048-bit long RSA key, • RA Network shall use 2048-bit long RSA key, • Subscribers shall use 2048-bit long RSA key pairs.

6.1.6. Public key parameters generation and quality checking

Fina CA shall carryout key pair generation using generation parameters in compliance with the standardised document ETSI TS 119 312 [20].

Compliance with the requirements for generation and verification of key parameter quality shall be ensured by using certified HSMs, software modules in Fina, secure cryptographic devices and QSCD devices according to the corresponding standards listed in Section 6.2.1 of this Certificate Policy, and strict abidance with the requirements listed in the certification documentation of these devices.



If a Custodian shall generate a key pair in accordance with Section 6.1.1.4 of this Certificate Policy, the key generation shall be carried out by using parameters for generation that comply with the standardised document ETSI TS 119 312 [20].

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

Below follows a description of the purpose of key certificates within the scope of this Certificate Policy.

The Fina CA certificate in the extension Key Usage shall have the set values keyCertSign and cRLSign. Fina CA shall only use the corresponding private key for:

• signing Subscriber certificates and certificates for LRA, • signing OCSP service responder certificates, • signing certificates for a qualified time-stamp, • signing the corresponding CRL.

All the certificates referred to in table 1.1 and 1.2 referred to in Section 1.1.2 of this Certificate Policy, except the Certificate for e-seal of Trusted List (NCP+), shall be intended for electronic signature support, for strong authentication and encryption of keys and in extension Key Usage shall have a set value digitalSignature and keyEncipherment.

Certificate for e-Seal of Trusted List (NCP+) shall be intended solely for support to the electronic seal of Trusted List.

6.2. Private Key Protection and Cryptographic Module Engineering Controls

6.2.1. Cryptographic module standards and controls

Private keys for subordinated Fina CAs shall be generated and protected by HSMs that comply with the requirements of the standard FIPS 140-2 [25] level 3.

For the certificate types listed in sections 6.1.1.2 and 6.1.1.3 a) of this Certificate Policy, the protection of private keys shall be carried out through QSCD devices that meet the requirements of the standard HR EN 419 211 [21] – [24] or secure cryptographic devices that meet the requirements of the standard FIPS 140-2 [25] level 2 or 3.

Fina shall monitor the certification status of these QSCD devices.

For Application certificate level 3 (NCP+), the protection of private keys shall be carried out through a HSM module that meets the requirements of the standard FIPS 140-2 [25] level 3.

For the certificate types listed in section 6.1.1.4 of this Certificate Policy, the protection of private keys shall be carried out in software protected token. For Application certificate level 2 (NCP), the protection of private keys shall be carried out in protected premises on the location of Bussines Entity. The Signatory or Business Entity shall be in charge of the method of protection of these private keys at the location of the Natural person - citizen or



Business Entity. Fina shall not set specific requirements for the storage and protection of these keys.

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

Private key multi-person control shall be a security measure requiring multi-person authorisation for private key control.

HSMs that protect private keys of Fina CAs' and OCSP services shall be located in the premises with the highest level of security within Fina PKI protected premises. Physical access to these HSMs shall be subject to dual control of authorised persons with Fina PKI trusted roles.

Control of private keys of Fina CAs and OCSP services shall be done by physical access to the HSM, with authorisation of two authorised persons with Fina PKI trusted roles.

6.2.3. Private key escrow

Private key escrow of Fina CAs private keys shall not be applied.

It is not allowed to escrow private key associated with unqualified certificates.

6.2.4. Private key backup

Fina CAs private keys backup shall be made in premises with the highest level of security within Fina PKI protected premises with dual control by authorised persons with Fina PKI trusted roles. Private Fina CA keys shall be retrieved from HSM solely in encrypted form, and in this form shall be copied and kept in secure premises with the highest level of security within the Fina PKI protected premises at separate locations.

Only authorised persons with Fina PKI trusted roles with dual control shall have physical access to Fina CAs' private keys backup.

Fina shall never carry out backup of Subscriber private keys associated with unqualified certificates.

The Signatory or Custodian shall be responsible for protection of private key copies for the certificate types referred to in Section 6.1.1.4 of this Certificate Policy, and shall be responsible in the event of their unauthorised use in the same way as the original, and in accordance with Section 9.6.3 of this Certificate Policy.

6.2.5. Private key archival

Fina shall not archive Fina PKI private keys and shall not archive Subscriber private keys.



6.2.6. Private key transfer into or from a cryptographic module

In the event of a transfer of a Fina CA private key from or into a HSM, when outside the HSM, the private key shall be protected in a way that shall ensure the same security level as when the key is inside the HSM. The transfer of a private key shall only be carried out by authorised persons with trusted roles in Fina PKI, along with dual control. The transfer of Fina CA private keys shall only be carried out for the purpose of creating backups.

During the transfer of private keys from one HSM into another HSM, the private key shall only be transferred to a HSM of equal or higher level of security compared to the HSM from which the private key is being transferred.

The transfer of private keys for the certificate types referred to in Section 6.1.1.4 of this Certificate Policy into another private key container shall be carried out by the Signatory or Custodian, so that the private key shall only be transferred to a cryptographic module of equal or higher level of security compared to the cryptographic module from which the private key is being transferred. Before transfer, the private key shall be adequately encrypted so that it shall be adequately protected during the transfer.

6.2.7. Private key storage on cryptographic module

The private keys of Fina CAs shall be protected by HSMs and may only be used if duly activated.

Private keys of Application certificates level 3 (NCP+) shall be protected by HSMs and they may only be used if duly activated.

There shall be no limitations regarding the format in which private keys shall be stored in HSMs.

6.2.8. Method of activating private key

The activation of the private keys of Fina CAs shall be carried out according to procedures and with compliance with the requirements set in the certification document of the HSM used with which Fina CA has protected the key, with dual control by authorised persons with Fina PKI trusted roles.

The activation of the private keys of Subscriber non-qualified certificates referred to in table 1.1. and 1.2. referred to in Section 1.1.2. of this Certificate Policy, shall be carried out by the associated Signatory, Custodian or Creator of a seal by using the corresponding activation data. Private key activation shall be carried out in a secure manner.

6.2.9. Method of deactivating private key

The deactivation of the private key of Fina CAs shall be carried out according to procedures and upon complying with requirements set in the certification document of the HSM used, with dual control by authorised persons with Fina PKI trusted roles.



The private keys of the certificates listed in Section 6.1.1.3 of this Certificate Policy shall be deactivated by cutting off power to the device, by stopping Subscriber signature or seal applications, and through an order from the Subscriber application for deactivation of the device.

The private keys of the certificates listed in Section 6.1.1.4 of this Certificate Policy, which are protected by a software token, shall be deactivated by stopping Subscriber signature and seal applications, and through an order from the Subscriber application for deactivation of the device.

A deactivated private key may be reused only after reactivation of the corresponding activation data.

6.2.10. Method of destroying private key

The procedure for destruction of a private Fina CA key shall be conducted 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 shall be carried out by authorised persons with trusted roles in Fina PKI with minimum dual control. The procedure for destruction of a Fina CA private key shall also include the destruction of all backup copies of this private key.

The destruction of a Fina CA private key shall be carried out in the way outlined in internal Fina documents which shall ensure that after the destruction of a private key it can no longer be recovered or reused.

A transcript shall be kept about the destruction of a Fina CA private key.

The destruction of Subscriber private keys stored in a HSM shall be carried out by a Custodian to ensure that once destroyed, no private key may be recovered or used.

The destruction of Subscriber private keys stored in QSCD or secure cryptographic devices shall be possible by physically destroying the secure cryptographic or QSCD device.

The destruction of private keys stored in software protected tokens shall be possible using appropriate applications or software tools for the destruction of data.

The destruction of private keys shall be the responsibility of the Signatory, Custodian or Creator of a seal.

6.2.11. Cryptographic Module Rating

The rating of HSMs, secure cryptographic and QSCD devices shall be carried out by certification according to corresponding standards for cryptographic modules listed in Section 6.2.1 of this Certificate Policy.



6.3. Other aspects of key pair management

6.3.1. Public key archival

Public keys of Fina CA shall comprise a constituent part of associated CA certificates that shall be archived in accordance with Sections 5.5.3 and 5.5.4 of this Certificate Policy, and they shall be kept in the archive for the period referred to in Section 5.5.2 of this Certificate Policy.

Public keys of Signatories and Business Entities shall comprise a constituent part of associated Subscriber certificates that shall be archived in accordance with Sections 5.5.3 and 5.5.4 of this Certificate Policy, and shall be kept in the archive for the period referred to in Section 5.5.2 of this Certificate Policy.

6.3.2. Certificate operational periods and key pair usage periods

The validity period of certificates according to types shall be defined in Table 6.1.

Certificate Term

Fina CA certificate 10 years

Standard level security certificates Not exceeding 5 years

Medium level security certificates 2 years

High level security certificates 1 year

Table 6.1 Certificate validity period

The validity period of Fina CA certificates shall not exceed the validity period of Fina Root CA certificates.

The validity period of a private key shall be equal to the validity period of the pertaining certificate. Certificates and pertaining keys shall not be used after the expiry of the validity period of the certificate, after certificate revocation and for the duration of its suspension.

6.4. Activation data

6.4.1. Activation data generation and installation

Activation data related to the private keys of Fina CAs shall be generated and installed during a formal private keys pair generation ceremony for subordinated Fina CAs.

Activation data for Fina RA network shall be generated by Registration officers in the Central RA Fina using the appropriate random number generator. Initial activation data for QSCD and secure cryptographic devices shall be generated by the Central RA or External RA, and the activation data shall be kept in a secure manner until their delivery to the Signatories, Custodians or Authorised Representatives.



Activation data for private keys related to certificates referred to in Section 6.1.1.4 of this Certificate Policy shall be generated by Signatory or Custodian.

Activation data for Application certificate level 3 (NCP+) certificates shall be generated by the Custodian.

If activation data are generated by Signatory then he/she shall be responsible for the protection and required quality of activation data.

If the Signatory or Authorised Representative generates activation data, then associated Business Entity shall be responsible for security and compliance with the stipulated quality of the activation data.

6.4.2. Activation data protection

Activation data connected with the private key of Fina CAs shall be kept in a secure manner.

Activation data of QSCD or secure cryptographic devices shall be distributed to Signatories, Custodians or Authorised representatives through separate channels in relation to the handover of QSCD or secure cryptographic devices.

If the activation data for the certificates referred to in Section 6.1.1.4 of this Certificate Policy shall be generated by Fina, then Fina shall forward these to the Authorised representative in a secure way.

Signatories, Custodians or Creator of a seals shall be in charge of and responsible for the protection and keeping of activation data of corresponding private keys.

Activation data shall not be kept together with a QSCD or secure cryptographic device to which it refers.

6.4.3. Other aspects of activation data

Activation data for the private keys of Subscriber certificates may be periodically modified to minimise the possibility of their disclosure.

This Certificate Policy shall not set any additional requirements on the life cycle of activation data of Subscriber certificates.

Additional rules about the terms and conditions, and life cycle of a Subject's activation data shall be specified in the Subscriber agreement.

6.5. Computer security controls

6.5.1. Specific computer security technical requirements

Only authorised persons after authentication shall have access to the IT system and applications in Fina PKI.



For all accounts that may directly initiate certificate issuance, two-factor authentication shall be necessary.

Modifications to and publication of the revocation status of certificates shall be carried out with two-factor authentication and mandatory control of access.

The Fina PKI system shall carryout continuous monitoring and shall have a detection system for the purpose of detecting, recording and timely reaction to attempts at unauthorised access to system resources.

6.5.2. Computer security rating

With the aim of providing secure and quality trust service, Fina has established an IT security management system in compliance with the standard ISO/IEC 27001[12].

6.6. Life cycle technical controls

6.6.1. System development controls

When procuring development software from an external subcontractor, Fina shall ensure the system development principles in the agreement with the supplier.

The analysis of security requirements shall be carried out in the design and specification phase of any development project of Fina PKI systems, to ensure that security has been incorporated in information technology in Fina PKI systems.

Software used to provide non-qualified certificate issuance services shall originate from a reliable source, and shall be approved by the person in charge of security in Fina PKI. New versions of software shall be tested in a test environment. Implementation of software in production shall be carried out in accordance with documented procedures of change management.

6.6.2. Security management controls

Fina shall carry out verification of all parts of the certification system in the Fina PKI production hierarchy, 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 of this Certificate Policy.

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 Business Entities that may be impacted by the security breach thereof.



6.6.3. Life cycle security controls

Fina shall carry 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 shall be protected by antivirus protection and the use of authorised software.

Monitoring of available certification system capacities shall be carried out, and the compliance of existing capacities for future needs of the system shall be assessed to plan their expansion in a timely manner.

6.7. Network security controls The computer network security of the Fina PKI system shall be based on the concept of network separation into network zones of different levels. Network zones shall be separated by firewalls allowing only necessary network traffic. Equal security measures shall be applied to all systems located within the same network zone.

Access and communication between zones shall be limited to authorised staff with trusted roles necessary for providing services. Unnecessary communication, accounts, ports, protocols and services shall be explicitly prohibited or deactivated.

The Fina PKI internal computer network shall be protected against unauthorised access, including access by Subscribers and third parties.

All systems critical for providing Trust Services shall be located in the Fina PKI protected premises.

CA systems shall be specially security adjusted and hardened.

The network component of Fina PKI systems shall be stored in a physically and logically secure environment and the compliance of its configurations shall be periodically checked.

6.8. Time-stamping Time-stamping is not used within the scope of certification services referred to in this Certificate Policy.

The time in the Fina certification system shall be synchronised with UTC time. Fina PKI audit logs shall 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 The profiles of certificates within the scope of this Certificate Policy issued by subordinated Fina CAs shall be aligned with the standard HRN EN 319 411-1 [15] and HRN EN 319 412 [16] - [18].

Subordinated FINA CAs shall issue certificates according to the profiles that shall be determined according to this Certificate Policy. Each type of certificate shall have a defined, unique certificate policy OID (CP OID), depending on the purpose of the certificate, the Policy according to which the certificate has been issued, its security level and the manner of protecting its associated private key.

Tables 1.1 and 1.2 of Section 1.1.2 of this Certificate Policy show a list of certificate types with pertaining CP OIDs issued by subordinated Fina CAs.

7.1.1. Version number(s)

Certificates shall be compliant with version 3 according to the X.509 specification.

7.1.2. Certificate extensions

The document with a description of the certificate profile shall be available on the website of Fina PKI repository referred to in Section 2.2 hereof.

7.1.3. Algorithm Object Identifiers (OID)

Algorithms with pertaining OID identifiers for all certificates issued by subordinated Fina CAs shall be 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

Name forms for Fina Root CA and its subordinated Fina CAs are described in Section 1.3.2 of this Certificate Policy.

Name forms for certificates issued by subordinated Fina CAs are described in Sections 3.1.1 and 3.1.4 of this Certificate Policy.

7.1.5. Name constraints

The extension Name Constraints shall not be used.



7.1.6. Certificate policy object identifier

The extension Certificate Policies certificates shall contain the corresponding CP OIDs of certification policy listed in tables 1.1 and 1.2 in Section 1.1.2. of this Certificate Policy.

7.1.7. Usage of policy constraints extension

The extension Policy Constraints shall not be used.

7.1.8. Policy qualifiers syntax and semantics

Policy qualifiers in the extension Certificate Policies shall contain two pointers in the form of a URI that contain the internet address of the Certification Practice Statement for Non-Qualified Certificates [32] in Croatian and English.

7.1.9. Processing semantics for the critical Certificate Policy extension

No stipulations.

7.2. CRL profile The CRL profile issued by subordinated Fine CAs shall be in compliance with the IETF RFC 5280 [27] recommendations.


CRL shall be compliant with 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 CAs 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

reasonCode NO Reason for the certificate revocation

Table 7.2 CRL and CRL Entry Extensions

7.3. OCSP profile The Fina OCSP service responder OCSP profile shall be in accordance with the IETF RFC 6960 recommendation [28].




The Fina OCSP service responder OCSP profile shall be in accordance with version 1 according to IETF RFC 6960 [28].

7.3.2. OCSP extensions

Fina OCSP services responders shall include the following extensions: 1. Nonce 2. Extended Revoked Definition



8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

Supervision over the work of Fina as a Trust Service Provider shall be regulated by Regulation (EU) No 910/2014 [1] and Electronic Signature Act [2] - [4] and shall be 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 a Signatory's 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 shall be carried out with the aim of confirming that Fina as a Trust Service Provider and provider of non-qualified certificate issuance services, meets the requirements stipulated in Regulation (EU) No 910/2014 [1], Electronic Signature Act [2] - [4], subordinate legislation [7] - [10] adopted pursuant to the Electronic Signature Act [2] - [4] and the standard ETSI EN 319 411-1 [15].

8.1. Frequency or circumstances of assessment Compliance audits of Fina PKI operations shall be external compliance audits and internal compliance audits.

Internal and external compliance audits of Fina PKI operation shall also be conducted in External RAs.

8.1.1. External Compliance Audit

External compliance audit shall be carried out at least every 12 months, in accordance with the requirements of standards ETSI EN 319 411-1 [15] i ETSI EN 319 403 [19].

8.1.2. Internal Compliance Audit

Internal compliance audit shall be carried out prior to the commencement of providing new trust services, periodically at least each 12 months, and after significant changes to Fina PKI operations.

8.2. Identity/qualifications of assessor External compliance audits shall be conducted by a conformity assessment body. The competence of the conformity assessment body and the qualification of the associated assessors shall be ensured by the accreditation of the conformity assessment body according to the standard ETSI EN 319 403 [19].

Internal compliance audits shall be conducted by internal compliance assessors who together have knowledge and understanding:

• about the provisions of the standard ETSI EN 319 411-1 [15], • about PKI areas and information security area, • about legislation in the area of providing trust services.



8.3. Assessor's relationship to assessed entity The conformity assessment body and associated assessors shall be independent of Fina and Fina's assessment system.

Internal compliance assessors shall 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 providing trust services:

• integrity and accuracy of documentation, • implementation of requirements for trust services, • organisational processes and procedures, • technical processes and procedures, • implementing information security measures, • trustworthy systems, • physical security at subject locations.

The description of the topics of compliance assessment shall be defined in the compliance assessment plan.

8.5. Actions taken as a result of deficiency In the event that non-compliance has been detected during the provision of trust services, Fina shall undertake the necessary steps to eliminate the non-compliance, and if applicable within the period set by the supervisory body.

During interruption of non-qualified certificate issuance due to the identified significant non-compliance, Fina may issue only those certificates that shall be identified as certificates for internal and testing purposes and it shall ensure that those certificates shall not be available to any other Subscriber.

8.6. Communication of results The results of internal compliance audits shall be of a confidential nature and Fina shall not make these public.

Fina shall make public the results of external compliance audits on the website of the repository referred to in Section 2.2 of this Certificate Policy. Non-compliance established during external compliance audits shall not be made public because they may contain confidential information.



9. OTHER BUSINESS AND LEGAL MATTERS

9.1. Fees Fina and External RA, in accordance with the terms and conditions referred to in the concluded agreement, shall notify Subscribers and Relying parties about all services to be charged for. Unless otherwise provided for in a separate agreement, services shall be charged in accordance with Fina's price list. The price list of all charged services shall be published on the website of the repository referred to in Section 2.2 of this Certificate Policy.

Fina shall reserve the right to price changes. Amendments to the price list shall be published on the website of the repository referred to in Section 2.2 of this Certificate Policy.

9.1.1. Certificate issuance or renewal fees

In accordance with the published price list, Fina shall charge fees for the services of issuance and renewal of certificates that Fina CAs issue to Subscribers.

9.1.2. Certificate access fees

Fina shall not charge certificate access fees.

9.1.3. Revocation or status information access fees

In accordance with the published price list, Fina shall charge fees for the certificate revocation service, and may determine and charge an appropriate fee for certificate suspension and reactivation.

Fina shall not charge for the service of providing information about the revocation or suspension status of certificates, which it provides as part of OCSP services or publication of CRL.

9.1.4. Fees for other services

Fina or External RA, in accordance with the terms and conditions referred to in the concluded agreement, may also decide to charge an appropriate fee for other services such as the registration of Business Entities or Subscribers, modification of data in certificates, delivery of certificates and equipment at the location of the Subscriber, etc.

No fee shall be charged for access to this Certificate Policy and CPNQC-eIDAS document [32].

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 shall possess financial stability and shall have at its disposal sufficient financial resources to ensure unhindered provision of certification services in accordance with this Certificate Policy.

9.2.1. Insurance coverage

Fina, as a certification services provider, shall insure itself against damage liability risks occurring while carrying out certification services.

Fina shall additionally insure 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.

Fina may request that the External RA insure itself against damages that may arise from providing services with External RA.

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 shall include all data in any form that participants exchange in any way in relation to establishing and providing certification service, and which participants label as confidential, or as being of a specific type or having a specific level of secrecy, or which shall be confidential by their nature as their unauthorised disclosure may 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 shall not be deemed confidential business information.

9.3.3. Responsibility to protect confidential information

Each participant shall protect confidential business information referred to in Section 9.3.1. of this Certificate Policy, that he/she 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 resulting damage.



9.4. Privacy of personal information Upon concluding a Subscriber agreement, Signatories shall mutually agree upon the publication of certificates in the public directory, that Fina may use and process data collected in the registration process in accordance with valid legislation, and mutually agree that Fina shall be authorised to keep this data for a duration of at least 10 years from the certificate expiry to which the records refer.

9.4.1. Privacy plan

Fina shall carryout technical, personnel and organisational protection measures of personal data in accordance with the Act on Personal Data Protection [11] 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 shall apply during the exchange of Subscriber personal data 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.

External RAs shall also carryout necessary measures for protection of personal data.

9.4.2. Information treated as private

During and after the Subscriber registration procedure, Fina or External RA shall be authorised to collect personal data required for valid Subscriber identification and other data required for valid certification service provision. Personal data collected by Fina or External RA that shall not be integrated into certificate contents, shall be deemed confidential personal data duly protected by Fina.

9.4.3. Information not deemed private

Personal data collected by Fina or External RA even after the Subscriber registration procedure and which shall be integrated in the certificate contents shall not be deemed confidential personal data due to their availability to all interested participants.

9.4.4. Responsibility to protect private information

Fina shall be responsible for the protection of personal data collected for the purpose of providing certification services.

Fina shall regulate responsibility for the protection of personal data in External RA by means of agreements with External RA.

9.4.5. Notice and consent to use private information

Aside from the needs of fulfilling legal obligations or contractual obligations according to certification agreements, Fina shall use or publish personal data only on the basis of written consent from the Subscriber.



9.4.6. Disclosure pursuant to judicial or administrative process

Fina shall not make the data referred to in Sections 9.3.1. and 9.4.2. of this Certificate Policy available except in cases stipulated by law or when required in writing by the competent court, administrative or other government body.

9.4.7. Other information disclosure circumstances

No stipulations.

9.5. Intellectual property rights Fina shall have intellectual property rights over this Certificate Policy document, as well as other Fina documentation published on the website of the repository referred to in Section 2.2

Fina shall not exercise intellectual property rights over the software used in Fina PKI which is owned by third parties.

The owner of private and public keys shall be the Subscriber, while solely the Signatory, Custodian or Creator of a seal shall be authorised for use of a private key, regardless of whether the key pair shall be generated by the Signatory, Custodian or Creator of a seal, or whether Fina generates it as the Trust Service Provider, and regardless of the manner in which the private key shall be protected.

Fina, as the provider of certification services, shall be the owner of certificates it issues.

9.6. Representations and warranties

9.6.1. CA representations and warranties

Fina shall be responsible for the compliance of this Certificate Policy with legislation, and for implementing the provisions stipulated in this Certificate Policy, CPSNQC-eIDAS document [32], certification services terms and conditions and in accordance with obligations in Subscriber agreements concluded with the Subscriber.

On the website of the repository referred to in Section 2.2 of this Certificate Policy, Fina shall publish the certification services terms and conditions, this Certificate Policy and all notifications and information concerning changes in operation that may affect Fina PKI participants in any way .

Fina as the Trust Service Provider shall be responsible for damage incurred while providing services caused by the Business Entities with whom Fina has subcontracted part of the certification services. This responsibility between Fina and the Business Entity shall be regulated by means of a separate agreement.



Fina shall be responsible for:

• proper authentication of Natural persons and/or Business Entity with the aim of certificate issuance,

• issuing certificates in a secure manner in order to preserve their authenticity and accuracy,

• compliance with its obligations.

In accordance with representations and warranties, Fina:

• upon providing certification services, shall apply the provisions of valid regulations referred to in Section 9.14 of this Certificate Policy,

• shall issue a certificate in a secure manner in order to preserve its authenticity and accuracy, basing it on the reliably established identity of a Natural person and/or Business Entity,

• shall issue a certificate with a profile in accordance with Section 7.1. of this Certificate Policy, and according to the certificate type listed in the certificate issuance application,

• shall ensure that Subscriber key pairs generated by Fina shall be generated in a secure manner ensuring private key confidentiality, in accordance with this Certificate Policy,

• shall for Subscriber key pairs that are generated by the Signatory, Custodian or Authorised representative on a secure cryptographic device or QSCD device, ensure that the key pairs are generated on a certified secure cryptographic device or QSCD devices, and that private key confidentiality shall be ensured in the manner described in this Certificate Policy,

• shall ensure verification that the Signatory or Business Entity shall be in possession of a private key whose pertaining public key shall be delivered for certification.

• shall, for certificates issued on secure cryptographic devices or QSCD devices, and for certificates issued in software protected tokens, ensure a secure manner of generating and delivery a private key and corresponding activation data to the Signatory, Custodian or Authorised representative in cases where the key pair shall be generated at the location of Fina CA or Fina LRA,

• shall ensure an adequately secure cryptographic device or QSCD device and its protected delivery to the Signatory, Custodian or Authorised representative,

• shall ensure that the issued certificate shall be accessible in accordance with Section 4.4.2 of this Certificate Policy,

• shall, pursuant to an authenticated and authorised request, revoke, suspend or reactivate a certificate and publish it on the list of revoked certificates after the conducted stipulated procedure,

• shall provide information about the revocation or suspension status of a certificate, • shall carry out the required security measures for protection of premises and

equipment of the certification system, • shall apply organisational and technical protection measures for keys and certificates

in accordance with this Certificate Policy,



• shall, in accordance with the business continuity plan, ensure the unhindered work

and maximum availability of certification services, • shall monitor the availability of capacities, shall plan maintenance and further

development of certification systems in accordance with future needs, standard requirements and development of technology,

• shall, in accordance with Sections 9.3 and 9.4 of this Certificate Policy, protect data deemed confidential and shall use this data solely for the needs of certification services within the scope of this Certificate Policy,

• shall ensure that internal and external verification of compliance of Fina as the provider of trust services are conducted in accordance with section 8.1 of this Certificate Policy.

In the event of a disruption in operations, Fina shall act in accordance with Section 5.8 of this Certificate Policy.

Limitations to Fina's responsibilities as a certification services provider shall be described in Section 9.8 of this Certificate Policy.

9.6.2. RA representations and warranties

The obligations and responsibilities of Fina RA Network and External RAs shall be as follows:

• carrying out registration and identification procedures for Natural persons and Business Entities in the manner stipulated by this Certificate Policy,

• forwarding integral, accurate and verified data about Subjects to Fina 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,

• protecting the archived Subscriber data against loss or confidentiality, integrity and accessibility violation as laid down in this Certificate Policy.

• notifying applicants for certificate issuance about the published and accessible terms and conditions of providing certification services and this Certificate Policy.

Aside from these obligations, the External RA shall abide by the obligations arising out of RA Service agreements concluded with Fina.

9.6.3. Subscriber representations and warranties

The Subscriber shall:

• in the registration process present itself in the manner stipulated in Chapter 3. and in Section 4.1.2.2. of this Certificate Policy,

• carefully use and keep electronic signature or electronic seal creation device, private keys and activation data in accordance with this Certificate Policy,



• undertake appropriate protection measures for electronic signature or electronic seal

creation devices, private keys and activation data against unauthorised access and use in accordance with Chapter 6. of this Certificate Policy,

• request, as soon as possible, the revocation or the suspension of its certificate in the event of private key compromise, the loss or damage to the electronic signature or electronic seal creation device, private key and activation data in accordance with Section 4.9. of this Certificate Policy,

• submit to the RA Network registration office all necessary data and information about changes that impact or may impact the accuracy of an electronic signature or electronic seal within the period set in Section 4.8 of this Certificate Policy,

• use the certificate and corresponding 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 of this Certificate Policy,

• use the certificate and corresponding private key in accordance with the provisions of section 4.5.1 of this Certificate Policy,

• act in accordance with all other provisions of this Certificate Policy that refer to Subscriber obligations.

The obligations and responsibilities of the Subscriber related to the use of private keys and certificates shall be described in Section 4.5.1 of this Certificate Policy.

The Signatory or Business Entity shall be responsible for the accuracy and correctness of data submitted in the registration procedure.

In the event of changes to contact data, the Subscriber shall forward the changes to Fina at the contact information listed in Section 9.11 of this Certificate Policy.

The Business Entity or person authorised for representation of the Business Entity shall, as soon as possible, request revocation of a business certificate issued to the Associated person who is no longer employed by the Business Entity or is no longer affiliated with the Business Entity in another way.

The Creator of a seal shall within the shortest possible time forward to Fina any subsequent changes to the Authorised representative connected with the electronic seal certificate.

The Subscriber shall be 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 shall make an autonomous and conscious decision on reasonable certificate reliance.

Reasonable reliance shall be deemed a decision by the Relying Party to rely on a certificate if at the time of reliance it has:



• undertaken the necessary precautionary measures and used the certificate for the

purposes stipulated in the Policy, that is, under circumstances in which reliance shall be 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 and suspension status, 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 in this Certificate Policy,

• checked if the electronic signature or electronic seal is created by a private key corresponding to the public key in the certificate within the certificate validity period,

• 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 of this Certificate Policy.

The Relying Party who has not abided by the regulations and this Certificate Policy, and has not acted in accordance with the obligations and responsibilities referred to in this Section shall alone bear the risks for reliance on such a certificate.

A Relying Party shall bear all the certificate reliance risks if it shall be aware of or has a reason to believe that facts exist that may cause personal or business damage due to the certificate use.

9.6.5. Representations and warranties of other participants

No stipulations.

9.7. Disclaimer of warranties Fina shall not be 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 shall not be liable for damage:

• suffered in the period from certificate revocation to the issuance of a new CRL, • damage due to unauthorised use of Subscriber keys and certificates, • damage occurring as a result of usage of a certificate not permitted by this Certificate

Policy, • damage caused by fraudulent or negligent use of the certificate, CRL or OCSP

service, • damage occurring as a result of a malfunction or error in the Subject's and the

Relying Party's software and hardware.



Fina shall not be 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 Certificate Policy.

9.8. Limitations of liability Fina's total financial liability for certificates issued according to this Certificate Policy and transactions carried out in reliance on certificates issued in such a way shall amount 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, shall be limited in accordance to the recommended financial limits shown in Table 1.5. Fina's maximum financial liability for non-qualified certificates shall be shown in Table 9.1.

Certificate category Fina's maximum financial liability

By category By transaction Total

Standard level security non-qualified certificates up to HRK 100,000 up to HRK 8,000

HRK 1,500,000

Medium level security non-qualified certificates up to HRK 600,000 up to HRK 80,000

High level security non-qualified certificates

up to HRK 800,000 up to HRK 400,000

Table 9.1 FINA's maximum financial liability

9.9. Indemnities Each participant shall be liable to the damaged party for damages caused by failing to comply with the provisions of this Certificate Policy and relevant regulations in force.

Signatory, Business Entity or Natural person on behalf of whom the Signatory shall act and who shall be represented by the Signatory, and Creator of a seal shall be liable to the damaged party, or any other participant if it obtains and uses the certificate issued by Fina based on false data provided during the certificate application.

The Relying Party shall be liable to the damaged party, or any other participant if it shall rely on the issued certificate without having checked its validity as described in Section 9.6.4. of this Certificate Policy or shall use it contrary to the purposes set out in this Certificate Policy.



9.10. Term and termination

9.10.1. Term

This Certificate Policy document shall be valid until a new Policy document comes into force or until its termination shall be 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 of this Certificate Policy, with an indication of the effective date. The new 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 Certificate Policy 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.

This document termination shall not be bound by nor shall it affect the validity of certificates issued under this document.

Fina may amend some provisions of the Policy in force, as specified in Section 9.12. of this Certificate Policy.

9.10.3. Effect of termination and survival

When a new version of the Policy shall come into force, the provisions of such document shall be applied to all certificates issued from that day on.

Certificates issued under previous Policies shall be valid until their termination, but they may be renewed in accordance with the new Policy document.

9.11. Individual notices and communication with participants

Individual communication with participants shall be primarily conducted through Fina's Call Centre, whose contact details are:

• Call free of charge 0800 0080 • e-mail: [email protected]

Individual notifications and other official written communication shall be 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 Certificate Policy shall be 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.5. of this Certificate Policy, containing a proposal for corrections or for the amendments to this document. The letter shall list the contact details of the person sending the modification proposal. After consideration, Fina PMA may accept, adjust or reject proposed modifications.

9.12.2. Notification mechanism and period

All amendments to this Certificate Policy document shall be published in electronic form on the website of the repository referred to in Section 2.2 of this Certificate Policy.

New versions of the Policy with amended OID of the Policy shall be published in electronic form on the website of the repository referred to in Section 2.2 of this Certificate Policy.

The effective date of amendments or newly-published Policy 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 Policy document that may materially affect the participants shall require the change of Policy OID. Fina shall determine the new OID for the new 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 by this Certificate




Policy, the participants shall try to reach an amicable solution. Otherwise, the matter shall be resolved by the competent court in Zagreb by application of Croatian law.

Participants may forward a complaint to Fina if they believe there exists a discrepancy in the content of services in relation to the published terms and conditions of service provision. Fina shall reply to a complaint. A complaint and the reply thereto shall be filed in the form of paper or electronic form to addresses specified under Section 9.11. of this Certificate Policy.

9.14. Governing law Fina shall provide trust services within the scope of this Certificate Policy in accordance with the provisions of Regulation (EU) No 910/2014 [1], implementing documents adopted pursuant to Regulation (EU) No 910/2014 [5] and [6], Electronic signature Act [2] - [4], subordinate acts adopted pursuant to this Act [7] - [9], and standardisation documents ETSI EN 319 401[14] and ETSI EN 319 411-1 [15].

9.15. Compliance with applicable law This Certificate Policy and certification services provision covered therein shall be in compliance with the regulations referred to in Section 9.14. of this Certificate Policy. All participants mutually agree with the application of Croatian law for interpretation of the applied provisions.

9.16. Miscellaneous provisions Fina shall publish this Certificate Policy, CPSNQC-eIDAS document [32] and certification services terms and conditions.

The certification services terms and conditions shall be communicated through a document in paper form or document in electronic form whose integrity shall be protected.

Before concluding a Subscriber agreement, Subscribers shall be informed about certification services terms and conditions. Acceptance of the certification services terms and conditions shall be a prerequisite for certificate issuance.

In procedures for certificate renewal, certificate renewal after expiry, revocation or modifications to data in the certificate, Fina shall notify the Signatory, Custodian or Authorised representative, and insofar as it is applicable, the Business Entity about possible changes to the certification services terms and conditions.

Date post:	29-May-2020
Category:	Documents
Upload:	others
View:	6 times
Download:	0 times