Fina - Certification Practice Statement for Non ...rdc.fina.hr/RDC-TDU2015/FinaRDC-TDU2015-CPSNQC5-1-en.pdf · Revision: 4-08/2016 Page: 1/165 FINA . CERTIFICATION PRACTICE STATEMENT

Certification Practice Statement for Non-Qualified Certificates

Classification: Designation: 75300201 Revision: 4-08/2016 Page: 1/165

FINA CERTIFICATION PRACTICE STATEMENT FOR

NON-QUALIFIED CERTIFICATES

(Public Document) Version 5.1

Effective date: 05/09/2016 Document OID: 1.3.124.1104.5.0.0.3.5.1



Document details

Document Name: Fina - Certification Practice Statement for Non-Qualified Certificates (Public Document)

Document OID: 1.3.124.1104.5.0.0.3.5.1

Document Type: Certification Practice Statement for Non-Qualified Certificates (CPSNQC)

Distribution Designation Public

Document Owner Fina

Contact [email protected]

Change History

Version Date Reason for Change

3.0 15/07/2002

3.1 15/09/2002 Amendment to certificate types and corrections to identified errors

3.2 31/03/2003 Amendment to registration and certificate issuance process, amendment to safety levels of certificate classes

4.0 06/11/2013 Alignment with Ordinances [5] and [6], List of Standardisation Documents [7] and the IETF RFC 3647 recommendation [22]. Certificate profile modifications and addition of the Business soft certificate (LCP).

4.1 01/10/2015 Incorporation of Amendments to Certification Practice Statement for Non-Qualified Certificates no. 1/4.0, alignment with Fina's business processes and the correction of errors detected in the text.

5.0 07/12/2015 Transition to the new, two-tier architecture of production CAs, transition to SHA-256 cryptographic algorithm and bigger key lengths, redefining non-qualified certificate types during production.

5.1 24/08/2016 Alignment with Fina PKI business processes and the correction of typographical errors

mailto:[email protected]



TABLE OF CONTENTS REFERENT DOCUMENTED INFORMATION ..................................................................12 Core Legislation ................................................................................................................12 Subordinate Regulations ...................................................................................................12 Other Legislation ...............................................................................................................12 European Parliament Directives ........................................................................................12 Standardization Documents ..............................................................................................12 Fina's Public Documents ...................................................................................................14 Fina's Internal Documents ................................................................................................14

1. INTRODUCTION ...........................................................................................................15 1.1. Overview ................................................................................................................15

1.1.1. Scope and purpose .........................................................................................15

1.1.2. Certificate types ..............................................................................................17

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

1.3.1. Policy management authority ..........................................................................19

1.3.2. Certification authorities ....................................................................................19

1.3.3. Registration authorities ....................................................................................21

1.3.4. Subscribers .....................................................................................................22

1.3.5. Relying parties ................................................................................................23

1.3.6. Other participants ............................................................................................23

1.4. Certificate usage ....................................................................................................23 1.4.1. Appropriate use of Fina RDC 2015 and Fina RDC-TDU 2015 authentication NCP+ normalized certificates ........................................................................................24

1.4.2. Prohibited certificate uses ...............................................................................28

1.5. CPSNQC Document Administration ..........................................................................28 1.5.1. Organization administering the CPSNQC document ..........................................28

1.5.2. Contact person ................................................................................................28

1.5.3. Person determining CPSNQC document suitability for the policy .......................28

1.5.4. CPSNQC approval procedures .........................................................................29

1.6. Definitions and Acronyms .......................................................................................29 1.6.1. Definitions .......................................................................................................29

1.6.2. Abbreviations ..................................................................................................38

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES ............................................40 2.1. Repositories ...........................................................................................................40 2.2. Publication of Certification Information ...................................................................40

2.2.1. FINA RDC 2015 repository ..............................................................................40

2.2.2. Fina RDC-TDU 2015 repository ......................................................................41

2.2.3. Fina QTSA repository ......................................................................................42



2.2.4. Contents Publication and Repository Management Procedures ......................42

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

3. IDENTIFICATION AND AUTHENTICATION .................................................................45 3.1. Naming............................................................................................................45

3.1.1. Types of names ...............................................................................................45

3.1.2. Need for names to be meaningful ....................................................................46

3.1.3. Anonymity or pseudonymity of Subscribers .....................................................47

3.1.4. Rules for interpreting various name forms .......................................................47

3.1.5. Uniqueness of names ......................................................................................51

3.1.6. Recognition, authentication and role of trademarks .........................................52

3.2. Initial identity validation ...................................................................................52

3.2.1. Method to prove possession of private key ......................................................52

3.2.2. Authentication of organization identity .............................................................54

3.2.3. Authentication of individual identity ..................................................................56

3.2.4. Non-verified Subscriber information ................................................................59

3.2.5. Validation of authority ......................................................................................59

3.2.6. Criteria for interoperation .................................................................................61

3.3. Identification and authentication for re-key requests ........................................61

3.3.1. Identification and authentication for routine re-key ..........................................61

3.3.2. Identification and authentication for re-key after revocation .............................63

3.4. Identification and authentication for revocation request ...................................63

3.4.1. Personal delivery of the revocation request to the RA Network .......................63

3.4.2. Mail or courier delivery of the revocation request ............................................64

3.4.3. Revocation request by phone ..........................................................................64

3.4.4. Revocation request by telefax .........................................................................64

3.4.5. Electronic delivery of the revocation request to e-mail address .......................64

3.4.6. Personal delivery of the suspension request to the RA Network ......................65

3.4.7. Mail or courier delivery of the suspension request ...........................................65

3.4.8. Suspension request by phone .........................................................................65

3.4.9. Suspension request by telefax ........................................................................66

3.4.10. Electronic delivery of the suspension request to e-mail address ......................66

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS ..................................67 4.1. Certificate Application .............................................................................................67

4.1.1. Who can submit a certificate application ..........................................................67



4.1.2. Enrolment process and responsibilities ...........................................................67

4.2. Certificate Application Processing ..........................................................................69 4.2.1. Performing identification and authentication functions .....................................69

4.2.2. Approval or rejection of certificate applications ................................................69

4.2.3. Time to process certificate applications ...........................................................70

4.3. Certificate Issuance ................................................................................................70 4.3.1. Fina CA actions during certificate issuance .....................................................70

4.3.2. Notification to subscribers by the CA of issuance of certificate ........................74

4.4. Certificate Acceptance ...........................................................................................75 4.4.1. Conduct constituting certificate acceptance .....................................................75

4.4.2. Publication of the certificate by the CA ............................................................76

4.4.3. Notification of certificate issuance by CA to other entities ................................76

4.5. Key Pair and Certificate Usage...............................................................................76 4.5.1. Subscriber private key and certificate usage ...................................................76

4.5.2. Relying party public key and certificate usage .................................................76

4.6. Certificate Renewal ................................................................................................77 4.6.1. Circumstance for certificate renewal ................................................................77

4.6.2. Who may request renewal ...............................................................................77

4.6.3. Processing certificate renewal requests ..........................................................78

4.6.4. Notification of new certificate issuance to subscriber .......................................78

4.6.5. Conduct constituting acceptance of a renewal certificate ................................78

4.6.6. Publication of the renewal certificate by the CA ...............................................78

4.6.7. Notification of certificate issuance by CA to other entities ................................78

4.7. Certificate Re-Key ..................................................................................................78 4.7.1. Circumstances for certificate re-key ................................................................78

4.7.2. Who may request certification of a new public key ..........................................79

4.7.3. Processing certificate re-keying requests ........................................................80


4.7.5. Conduct constituting acceptance of a re-keyed certificate ...............................84

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

4.7.7. Notification of re-keyed certificate by the CA to other entities ..........................84

4.8. Certificate modification ...........................................................................................84 4.8.1. Circumstances for certificate modification .......................................................84

4.8.2. Who may request certificate modification ........................................................85

4.8.3. Processing certificate modification requests ....................................................85




4.8.5. Conduct constituting acceptance of the modified certificate.............................85

4.8.6. Publication of the modified certificate by the CA ..............................................85

4.8.7. Notification of the modified certificate issuance to other entities ......................85

4.9. Certificate revocation and suspension ....................................................................86 4.9.1. Circumstances for revocation ..........................................................................86

4.9.2. Who can request revocation ............................................................................86

4.9.3. Procedure for revocation request ....................................................................87

4.9.4. Revocation request grace period .....................................................................89

4.9.5. Time within which CA must process revocation request ..................................89

4.9.6. Revocation checking requirement for relying parties .......................................89

4.9.7. CRL issuance frequency .................................................................................89

4.9.8. Maximum latency for CRLs .............................................................................90

4.9.9. On-line revocation/status checking availability.................................................90

4.9.10. On-line revocation checking requirements .......................................................90

4.9.11. Other forms of revocation advertisements available ........................................90

4.9.12. Special requirements re key compromise ........................................................90

4.9.13. Circumstances for suspension ........................................................................90

4.9.14. Who can request suspension ..........................................................................91

4.9.15. Procedure for suspension request ...................................................................92

4.9.16. Limits on suspension period ............................................................................96

4.10. Certificate status services.......................................................................................97 4.10.1. Operational characteristics ..............................................................................97

4.10.2. Service availability ...........................................................................................98

4.10.3. Optional features .............................................................................................98

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

4.12.1. Key escrow and recovery policy and practices ................................................99

4.12.2. Session key encapsulation and recovery policy and practices ....................... 100

5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS .................................... 101 5.1. Physical controls .................................................................................................. 101

5.1.1. Site location and construction ........................................................................ 101

5.1.2. Physical access ............................................................................................. 102

5.1.3. Power and air conditioning ............................................................................ 102

5.1.4. Water exposures ........................................................................................... 102

5.1.5. Fire prevention and protection ....................................................................... 102

5.1.6. Media storage ............................................................................................... 102



5.1.7. Waste disposal .............................................................................................. 102

5.1.8. Off-site backup .............................................................................................. 103

5.2. Procedural controls .............................................................................................. 103 5.2.1. Trusted roles ................................................................................................. 103

5.2.2. Number of persons required per task ............................................................ 103

5.2.3. Identification and authentication for each role ............................................... 103

5.2.4. Roles requiring separation of duties .............................................................. 104

5.3. Personnel controls................................................................................................ 104 5.3.1. Qualifications, experience and clearance requirements ................................. 104

5.3.2. Background check procedures ...................................................................... 104

5.3.3. Training requirements ................................................................................... 104

5.3.4. Retraining frequency and requirements ......................................................... 104

5.3.5. Job rotation frequency and sequence ............................................................ 105

5.3.6. Sanctions for unauthorised actions ................................................................ 105

5.3.7. Independent contractor requirements ............................................................ 105

5.3.8. Documentation supplied to personnel ........................................................... 105

5.4. Audit logging procedures ...................................................................................... 105 5.4.1. Types of events recorded .............................................................................. 105

5.4.2. Frequency of processing log ......................................................................... 106

5.4.3. Retention Period for audit log ........................................................................ 106

5.4.4. Protection of audit log .................................................................................... 106

5.4.5. Audit log backup procedures ......................................................................... 106

5.4.6. Audit logAudit collection system (internal vs. external) .................................. 106

5.4.7. Notification to event-causing subject ............................................................. 107

5.4.8. Vulnerability assessment ............................................................................... 107

5.5. Records archival .................................................................................................. 107 5.5.1. Types of records archived ............................................................................. 107

5.5.2. Retention period for archive .......................................................................... 107

5.5.3. Protection of archive...................................................................................... 107

5.5.4. Archive backup procedures ........................................................................... 108

5.5.5. Requirements for time-stamping of records ................................................... 108

5.5.6. Archive collection system (internal or external) .............................................. 108

5.5.7. Procedures to obtain and verify archive information ...................................... 108

5.6. Key Changeover .................................................................................................. 108 5.7. Compromise and disaster recovery ...................................................................... 109

5.7.1. Incident and compromise handling procedures ............................................. 109



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

5.7.3. Entity private key compromise procedures .................................................... 110

5.7.4. Business Continuity capabilities after a disaster ............................................ 111

5.8. CA or RA termination ........................................................................................... 111 6. TECHNICAL SECURITY CONTROLS ........................................................................ 113

6.1. Key pair generation and installation ...................................................................... 113 6.1.1. Key pair generation ....................................................................................... 113

6.1.2. Private key delivery to subscriber .................................................................. 117

6.1.3. Public Key Delivery to certificate issuer ......................................................... 118

6.1.4. CA public key delivery to relying parties ........................................................ 118

6.1.5. Key sizes ....................................................................................................... 118

6.1.6. Public key parameter generation and quality checking .................................. 119

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

6.2. Private Key Protection and Cryptographic Module Engineering Controls .............. 120 6.2.1. Cryptographic module standards and controls............................................... 120

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

6.2.3. Private key escrow ........................................................................................ 121

6.2.4. Private key backup ........................................................................................ 121

6.2.5. Private key archival ....................................................................................... 122

6.2.6. Private key transfer into or from a cryptographic module ............................... 122

6.2.7. Private key storage on cryptographic module ................................................ 122

6.2.8. Method of activating private key .................................................................... 123

6.2.9. Method of deactivating private key ................................................................ 123

6.2.10. The method for destroying private key .......................................................... 124

6.2.11. Cryptographic module rating ......................................................................... 124

6.3. Other aspects of key pair management ................................................................ 124 6.3.1. Public key archival ........................................................................................ 124

6.3.2. Certificate operational periods and key pair usage periods............................ 125

6.4. Activation data ...................................................................................................... 126 6.4.1. Activation data generation and installation .................................................... 126

6.4.2. Activation data protection .............................................................................. 126

6.4.3. Other aspects of activation data .................................................................... 127

6.5. Computer security controls ................................................................................... 128 6.5.1. Specific computer security technical requirements ........................................ 128

6.5.2. Computer security rating ............................................................................... 128

6.6. Life cycle technical controls .................................................................................. 128



6.6.1. System development controls ....................................................................... 128

6.6.2. Security management controls ...................................................................... 128

6.6.3. Life cycle security controls............................................................................. 128

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

7. CERTIFICATE, CRL, AND OCSP PROFILES ............................................................. 130 7.1. Certificate profile .................................................................................................. 130

7.1.1 Version number(s) ......................................................................................... 130

7.1.2 Certificate extensions .................................................................................... 130

7.1.3 Algorithm object identifiers ............................................................................ 142

7.1.4 Name forms .................................................................................................. 142

7.1.5 Name constraints .......................................................................................... 143

7.1.6 Certificate policy object identifier ................................................................... 143

7.1.7 Usage of Policy Constraints extension .......................................................... 143

7.1.8 Policy qualifiers syntax and semantics .......................................................... 143

7.1.9 Processing semantics for the critical Certificate Policies extension ............... 143

7.2. CRL Profile ........................................................................................................... 143 7.2.1 Version number(s) ......................................................................................... 143

7.2.2 CRL and CRL entry extensions ..................................................................... 143

7.3. OCSP profile ........................................................................................................ 144 7.3.1 Version number(s) ......................................................................................... 144

7.3.2 OCSP extensions .......................................................................................... 144

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS ................................................ 145 8.1. Frequency or circumstances of assessment ......................................................... 145 8.2. Identity/qualifications of assessor ......................................................................... 145 8.3. Assessor's relationship to assessed entity ............................................................ 146 8.4. Topics covered by assessment ............................................................................ 146 8.5. Actions taken as a result of deficiency .................................................................. 146 8.6. Communication of results ..................................................................................... 147 9.1. Fees ..................................................................................................................... 148

9.1.1. Certificate issuance or renewal fees .............................................................. 148

9.1.2. Certificate access fees .................................................................................. 148

9.1.3. Revocation or status information access fees................................................ 148

9.1.4. Fees for other services .................................................................................. 148

9.1.5. Refund policy ................................................................................................ 149

9.2. Financial responsibility ......................................................................................... 149 9.2.1. Insurance coverage ....................................................................................... 149

9.2.2. Other assets .................................................................................................. 149



9.2.3. Insurance or warranty coverage for end-entities ............................................ 149

9.3. Confidentiality of business information ................................................................. 150 9.3.1. Scope of Confidential business information ................................................... 150

9.3.2. Information not within the scope of confidential information ........................... 150

9.3.3. Responsibility to protect confidential information .......................................... 151

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

9.4.2. Information treated as private ........................................................................ 151

9.4.3. Information not deemed private ..................................................................... 152

9.4.4. Responsibility to protect private information .................................................. 152

9.4.5. Notice and consent to use private information ............................................... 152

9.4.6. Disclosure pursuant to judicial or administrative process ............................... 152

9.4.7. Other information disclosure circumstances .................................................. 153

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

9.6.1. CA representations and warranties ............................................................... 153

9.6.2. RA representations and warranties ............................................................... 156

9.6.3. Subscriber representations and warranties ................................................... 156

9.6.4. Relying party representations and warranties ................................................ 157

9.6.5. Representations and warranties of other participants .................................... 158

9.6.6. QTSA obligations and responsibilities ........................................................... 158

9.7. Disclaimers of warranties ..................................................................................... 160 9.8. Limitations of liability ............................................................................................ 160 9.9. Indemnities ........................................................................................................... 161 9.10. Term and termination ........................................................................................... 162

9.10.1. Term ............................................................................................................. 162

9.10.2. Termination ................................................................................................... 162

9.10.3. Effect of termination and survival................................................................... 162

9.11. Individual notices and communication with participants ........................................ 162 9.12. Amendments ........................................................................................................ 163

9.12.1. Procedure for amendment ............................................................................. 163

9.12.2. Notification mechanism and periods .............................................................. 163

9.12.3. Circumstances under which OID must be changed ....................................... 164

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



COPYRIGHT This Certification Practice Statement for Non-Qualified Certificates is the property of Fina, administered by Fina PMA and subject to copyright in accordance with laws of the Republic of Croatia.



REFERENT DOCUMENTED INFORMATION

Core Legislation [1] Electronic Signature Act (Official Gazette 10/2002) [2] Act on Amendments to the Electronic Signature Act (Official Gazette 80/2008) [3] Act on Amendments to the Electronic Signature Act (Official Gazette 30/2014)

Subordinate Regulations [4] Ordinance on the Registry of Certification Service Providers in the Republic of

Croatia (Official Gazette 107/2010) [5] 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)

[6] 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)

[7] List of Standardization Documents referring to the Implementation of the Electronic Signature Act and the Ordinance on the Creation of Electronic Signature, the Use of Signature Creation Devices and on General and Specific Terms and Conditions for Providers of Time-Stamping and Certification Services in the Certification Services Providers' Operations in the Republic of Croatia (Official Gazette 89/2013)

[8] 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 [9] The Act on Personal Data Protection (Official Gazette 106/2012)

European Parliament Directives [10] Directive 1999/93/EC of the European Parliament and of the Council of

13 December 1999 on a Community framework for electronic signatures

Standardization Documents [11] HRN ETSI/EN 319 411-2 V1.1.1:2013 Electronic Signatures and

Infrastructures (ESI) – Policy and Security Requirements for Trust Service Providers issuing Certificates – Part 2: Policy Requirements for Certification Authorities issuing Qualified Certificates (EN 319 411-2 V1.1.1:2013)



[12] HRN ETSI/EN 319 411-3 V1.1.1:2013 Electronic Signatures and

Infrastructures (ESI) – Policy and Security Requirements for Trust Service Providers issuing Certificates – Part 3: Policy Requirements for Certification Authorities issuing Public Key Certificates (EN 319 411-3 V1.1.1:2013)

[13] HRN ETSI/EN 319 412-5 V1.1.1:2013 Electronic Signatures and Infrastructures (ESI) – Profiles for Trust Service Providers issuing Certificates – Part 5: Extension for Qualified Certificate Profile (EN 319 412-5 V1.1.1:2013)

[14] ETSI TS 119 612 V1.2.1:2014 Electronic Signatures and Infrastructures (ESI) – Trusted Lists

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

[16] ETSI TS 119 403 - Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment

[17] HRS ETSI/TS 102 023 V1.2.2:2009 Electronic Signatures and Infrastructures (ESI) – Policy Requirements for Time Stamping Authorities (ETSI TS 102 023 V1.2.2:2008)

[18] CEN Workshop Agreement 14167-1:2003 - Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures - Part 1: System Security Requirements

[19] CEN Workshop Agreement 14169:2004 - Secure signature-creation devices “EAL 4+”

[20] IETF RFC 3161 (2001) Internet X.509: Public Key Infrastructure: Time Stamp Protocol (TSP)

[21] IETF RFC 3279 - Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile

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

[23] IETF RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

[24] IETF RFC 5322 - Internet Message Format [25] IETF RFC 6960 X.509 Internet Public Key Infrastructure - On-line Certificate

Status Protocol – OCSP [26] HRN ISO/IEC 15408:2013 (parts 1 to 3) Information technology – Security

techniques – Evaluation criteria for IT security – Part 1: Introduction and general model, – Part 2: Security functional requirements, – Part 3: Security assurance requirements (ISO/IEC 15408-1:2009, ISO/IEC 15408-2:2008, ISO/IEC 15408-3:2008)

[27] HRN ISO/IEC 27001:2006 Information technology – Security techniques – Information security management systems – Requirements (ISO/IEC 27001:2005)



[28] ISO/IEC 27002:2013 - Information technology - Security techniques - Code of

practice for information security controls [29] NIST FIPS PUB 140-1:1994 - Security Requirements for Cryptographic

Modules [30] NIST FIPS PUB 140-2:2002 - Security Requirements for Cryptographic

Modules [31] NIST FIPS PUB 186-3: Digital Signature Standard (DSS) [32] ITU-T Recommendation X.509:2000 / ISO/IEC 9594-8:2001: Information

technology – Open Systems Interconnection – The Directory: Public-key attribute certificate frameworks

[33] ITU-T Recommendation X.501:2008 – Information technology – Open Systems Interconnection – The Directory: Models

[34] CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates v1.2.3

Fina's Public Documents [35] Fina – Certificate Policy Fina Root CA, v1.0 [36] Fina – Certificate Policy, v5.1 [37] Fina – Qualified Time-Stamping Service Policy. v1.0

Fina's Internal Documents [38] Fina - Certification Practice Statement Fina Root CA, CPSROOT, ver. 1.0 [39] Fina - Certification Practice Statement for Qualified Certificates, CPSQC, ver.

5.1



1. INTRODUCTION

As a Trusted Third Party, Fina has been providing certification services since 2003. Certification services are in accordance with legal regulations on electronic signature in the Republic of Croatia [1] – [8] and the EU Directive on electronic signatures [10], as well as with the applicable international standards within the scope of certification services provision. Fina continuously keeps track of Subscribers' needs, technology development and modifications to applicable standards within the scope of certification services provision, and improves and adjusts its PKI system accordingly, while putting efforts into adjusting its products and services as much as possible to the cross-border interoperability demands.

1.1. Overview

Hierarchical structure of Fina PKI based on Fina Root CA is based on two-tier architecture of production Certificate Authorities (hereinafter referred to as: CA).

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

• Root Certificate Authority: Fina Root CA • Two subordinate Certificate Authorities:

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

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

The Policy related to Fina Root CA and the entire Fina PKI hierarchy based on Fina Root CA are described in the document Certificate Policy Fina Root CA [35].

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

The Policy related to Fina Root CA and the entire Fina PKI hierarchy based on Fina Root CA are described in the document Certificate Policy Fina Root CA, CPSROOT [38].

1.1.1. Scope and purpose

This Fina – Certification Practice Statement for Non-Qualified Certificates (Public Document) (hereinafter referred to as: CPSNQC) corresponds to the document „Internal Certification Practice Statement“ defined in the Ordinance on the Registry of Certification Services Providers [4] and describes processes and procedures implemented by Fina PKI to issuance and management of life cycle of production digital certificates which are not considered qualified certificates within the meaning of the Electronic Signature Act [1], [2] and [3], (hereinafter referred to as: non-qualified certificates), all pursuant to requirements stipulated in Fina PKI – Certificate Policy (hereinafter referred to as: the Certificate Policy) [36] in the part referring to issuance of non-qualified certificates.



Pursuant to the Policy [36], Fina PKI issues the following types of non-qualified certificates: normalized certificates and lightweight certificates.

Normalized certificates are certificates in terms of the Electronic Signature Act [1], [2] and [3], and they are used for electronic signature support. Normalized certificates with the designation NCP are in line with the general rules for Normalized Certificate Policy (NCP) of the HRN ETSI/EN 319 411-3 standard [12], and normalized certificates with the designation NCP+ are in line with the general rules for Extended Normalized Certificate Policy (NCP+) of the HRN ETSI/EN 319 411-3 standard [12]. In addition to being used as electronic signature support, normalized certificates may also be used for other purposes, such as authentication and encryption.

Lightweight certificates are certificates in terms of the Electronic Signature Act [1], [2] and [3], and they are used for electronic signature support. Lightweight certificates are in line with Lightweight Certificate Policy (LCP) under the HRN ETSI/EN 319 411-3 standard [12]. In addition to being used as electronic signature support, lightweight certificates may also be used for other purposes, such as authentication and encryption. The aforementioned lightweight certificates shall have the LCP designation.

Normalized and lightweight certificates are not considered qualified certificates in terms of the Electronic Signature Act [1], [2] and [3], therefore, they shall hereinafter be collectively referred to as non-qualified certificates.

Production certificates within the scope of this CPSNQC document, together with production certificates within the scope of CPSQC documents, comprise the Registry of Digital Certificates (Fina RDC) consisting of two certification authorities (CA) within the scope of this CPSNQC document: Fina RDC 2015 and Fina RDC-TDU 2015.

This CPSNQC document intended for publications constitutes an extract from Fina's internal Certification Practice Statement for Qualified Certificates, version 5.1 and provides Fina PKI participants with Fina PKI processes and procedures, not revealing thereby confidential business information of Fina contained in its internal rules, procedures and other internal documents of Fina.

CPSNQC is aligned with the document Policy [36] in the section referring to non-qualified certificates. Policy [36] is available on the website http://www.fina.hr/finadigicert.

In addition to processes and procedures for issuance and management of life cycle of non-qualified certificates, this CPSNQC document also comprises processes and procedures implemented at Fina PKI for qualified time-stamping service policy, whose policy is described in the document Fina – Qualified Time-Stamping Service Policy [37], (hereinafter referred to as: Qualified Time-Stamping Service Policy) in sections in which this CPSNQC relates to such service. Qualified Time-Stamping Service Policy [37] is available on the website http://www.fina.hr/finadigicert.

Within the scope of this CPSQC document, production CAs at Fina PKI shall be deemed Fina RDC 2015 and Fina RDC-TDU 2015 (hereinafter jointly referred to as: Fina CAs).

http://www.fina.hr/finadigicert




In parts of this CPSNQC document where the term Fina CA is being used, all processes and procedures referred to in certain document points implemented by Fina CAs are binding for both production Fina CAs operating within Fina PKI. In case of differences in the implementation of processes and procedures between Fina RDC 2015 and Fina RDC-TDU 2015, such differences will be noted separately in points in which they appear.

1.1.2. Certificate types

Fina, as a Certification Service Provider, shall issue to Subscribers the following non-qualified certificate groups within the scope of this CPSNQC document:

• Fina RDC 2015 Personal Normalized Certificates; • Fina RDC 2015 Business Normalized Certificates; • Fina RDC 2015 Business Lightweight LCP Certificates; • Fina RDC-TDU 2015 Normalized Certificates; • Fina RDC 2015 Business Normalized Certificates for IT equipment; • Fina RDC 2015 Administrative Normalized Certificates (for Fina's authorised

employees only).

Each certificate type has a title and a unique certificate policy OID (CP OID).

Table 1.1 shows non-qualified certificate types within the scope of this CPSNQC document with their titles and pertaining CP OIDs, according to groups for each Fina CA.

Fina Register of Digital Certificates (Fina RDC) Fina RDC 2015

Fina RDC 2015 Personal Normalized Certificates

Personal authentication N2 certificate (NCP+)

CP OID: 1.3.124.1104.5.12.1.4.2

Personal soft certificate (NCP) CP OID: 1.3.124.1104.5.12.1.3.1

Fina RDC 2015 Business Normalized certificates

Business authentication N2 certificate (NCP+)

CP OID: 1.3.124.1104.5.12.2.4.2

Business soft certificate (NCP) CP OID: 1.3.124.1104.5.12.2.3.1

Fina RDC 2015 Business Lightweight LCP Certificates

Business soft certificate (LCP) CP OID: 1.3.124.1104.5.12.2.5.1



Fina Register of Digital Certificates (Fina RDC) Fina RDC 2015

Fina RDC 2015 Business Normalized Certificates for IT equipment

SSL Certificate Level 2 (NCP) CP OID: 1.3.124.1104.5.12.3.3.2

SSL Certificate Level 3 (NCP+) CP OID: 1.3.124.1104.5.12.3.4.3

Application Certificate Level 1 (NCP) CP OID: 1.3.124.1104.5.12.5.3.1

Application Certificate Level 2 (NCP) CP OID: 1.3.124.1104.5.12.5.3.2

Application Certificate Level 2 (NCP+) CP OID: 1.3.124.1104.5.12.5.4.2

Application Certificate Level 3 (NCP+) CP OID: 1.3.124.1104.5.12.5.4.3

Certificate for signing Trusted List (NCP+)

CP OID: 1.3.124.1104.5.12.8.4.2.

Time-Stamp Certificate (NCP+) CP OID: 1.3.124.1104.5.12.52.4.3

OCSP service response signing certificate (NCP+)

CP OID: 1.3.124.1104.5.12.9.4.3

Fina RDC 2015 Administrative Normalized Certificates

Administrative N2 certificate (NCP+) CP OID: 1.3.124.1104.5.12.6.4.2

Fina Register of Digital Certificates (Fina RDC) Fina RDC-TDU 2015

Fina RDC-TDU 2015 Normalized Certificates

TDU authentication N2 certificate (NCP+)

CP OID: 1.3.124.1104.5.22.2.4.2

Fina RDC-TDU 2015 Certificates for IT equipment

OCSP service response signing certificate (NCP+)

CP OID: 1.3.124.1104.5.22.9.4.3

Table 1.1 Certificate types

1.2. Document name and identification

Listed below are the Document Name and the corresponding identification data. • Document Name: Fina PKI - Certification Practice Statement for Non-Qualified

Certificates (Public Document) • Version: 5.1 • Effective date: 05/09/2016 • OID: 1.3.124.1104.5.0.0.3.5.1

1.3. PKI participants Fina PKI participants within the scope of this CPSNQC document are natural persons, authorities within Fina and legal entities operating in Fina PKI as certification service



subscribers, or as providers of certain sub-services related to certification work used by Fina for the purpose of certification services provision.

Participants within Fina PKI are:

• Policy Management Authority (PMA); • Certification Authorities (CAs); • Qualified Time-Stamping Authority (QTSA); • Registration Network (RA Network) consisting of Registration Authorities (RAs) and

Local Registration Authorities (LRAs); • Subscribers; • Relying Parties; • Other participants;

− PKI IT equipment manufacturers; − Security device manufacturers (smart cards, USB tokens etc.); − Authorised supervisory bodies.

1.3.1. Policy management authority

Policy Management Authority within Fina shall be Fina PMA. Fina PMA is the authority authorised and responsible for creating, implementing and administering Certificate Policy, its relevant documentation and procedures, as well as controlling its implementation. Fina PMA consists of the employees of the Office for e-business policy management, which is in charge of managing the certification rules, and the director of Financial and Electronic Services Sector.

1.3.2. Certification authorities

Certification Authorities within Fina PKI under this CPSNQC document are Fina RDC 2015 and Fina RDC-TDU 2015 (hereinafter jointly referred to as: Fina CAs). Fina CAs have to perform their services of issuing certificates and managing life cycles of issued certificates pursuant to the procedures from this CPSNQC document, which is aligned with the Policy [36].

Obligations and responsibilities of Fina CAs are listed under Section 9.6.1 of this CPSNQC document. Procedures implemented by Fina CAs in order to meet the requirements for non-qualified certificates under the Policy [36] are described in this CPSNQC document.

1.3.2.1. Fina RDC 2015

Fina RDC 2015 under this CPSNQC document issues certificates for the public, which certificates belong to the following groups of non-qualified certificate types:

• Fina RDC 2015 Personal Normalized Certificates; • Fina RDC 2015 Business Normalized Certificates; • Fina RDC 2015 Business Lightweight (LCP) Certificates; • Fina RDC 2015 Business Normalized Certificates for IT equipment; • Fina RDC 2015 Administrative Certificates.



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

Field Fina RDC 2015 Value Version V3, value=“2“ serialNumber The certificate serial number with 32 bits of entropy (length of serial

number: 12 or 13 octet) signatureAlgorithm sha256WithRSAEncryption (OID: 1.2.840.113549.1.1.11) Issuer cn=Fina Root CA, o= Financijska agencija, c=HR Validity NotBefore: Date and time of issuance

NotAfter: 10 years after the date and time of issuance Subject cn=Fina RDC 2015, o= Financijska agencija, c=HR SubjectPublicKeyInfo rsaEncryption (OID: 1.2.840.113549.1.1.1), 4096-bit long public key

Table 1.2 Fina RDC-TDU 2015 certificate basic data

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

1.3.2.2. Fina RDC-TDU 2015

Fina RDC-TDU 2015 under this CPSNQC document issues normalized certificates to state officials and state administration authorities’ employees. Fina RDC-TDU 2015 certificate basic data are provided in Table 1.3:

Field Fina RDC-TDU 2015 Value Version V3, value=“2“ serialNumber The certificate serial number with 32 bits of entropy (length of serial

number: 12 or 13 octets) signatureAlgorithm sha256WithRSAEncryption (OID: 1.2.840.113549.1.1.11) Issuer cn=Fina Root CA, o= Financijska agencija, c=HR Validity NotBefore: Date and time of issuance

NotAfter: 10 years after the date and time of issuance Subject cn=Fina RDC-TDU 2015, o= Financijska agencija, c=HR SubjectPublicKeyInfo rsaEncryption (OID: 1.2.840.113549.1.1.1), 4096-bit long public key

Table 1.3 Fina RDC-TDU 2015 certificate basic data

Fina RDC-TDU 2015 CA-certificate is available on the following website: http://rdc.fina.hr/RDC-TDU2015/FinaRDC-TDUCA2015.cer.

1.3.2.3. Time-Stamping Authority

As a certification authority, Fina has an established role of issuing qualified time-stamps through the Fina's time-stamping service (hereinafter referred to as: Fina QTSA 2015). Fina QTSA 2015 has to provide qualified time-stamping service (hereinafter referred to as: Time-Stamp) pursuant to procedures referred to in this CPSNQC (Public Document), which is, in parts related to time-stamping service provision, aligned with the document Time-Stamping Service Policy [37].

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

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



Obligations and responsibilities of Fina as a time-stamping authority are listed under section 9.6.6 of this CPSNQC document. Procedures implemented by Fina QTSA 2015 in order to provide the time-stamping service are described in this CPSNQC document.

Basic data on the Fina QTSA 2015 certificate for time-stamps signing are provided in Table 1.4.

Field Fina QTSA 2015 Value Version V3, value=“2“

serialNumber Certificate serial number with 64-bits entropy (serial number length: 16 or 17 bytes)

signatureAlgorithm sha256WithRSAEncryption (OID: 1.2.840.113549.1.1.11) Issuer cn=Fina RDC 2015, o= Financijska agencija, c=HR

Validity NotBefore: Date and time of issuance NotAfter: 10 years after the date and time of issuance

Subject cn= Fina QTSA1 2015 o= Financijska agencija c= HR

SubjectPublicKeyInfo rsaEncryption (OID: 1.2.840.113549.1.1.1), 2048-bit long public key Table 1.4 Basic data on a Fina QTSA 2015 time stamp certificate

1.3.3. Registration authorities

Subscriber registration for Fina CAs is performed in Fina Registration Authorities. For the purpose of Subscriber registration for Fina CAs, Fina has entered into agreements on registration services provision with other business entities.

Fina PKI has an organized Registration Authorities network (hereinafter referred to as: RA Network) which registers Subscribers for Fina CAs. RA Network consists of Fina RA Network and the network of a particular sub-contracted External RA.

The Fina RA Network consist of the Central Fina RA as part of the RDC Department and a network of local registration authorities across the Fina’s business network (hereinafter referred to as: Fina LRA). The Central Fina RA consists of authorised persons from the RDC Department (hereinafter referred to as: officers of the Central Fina RA). Subscriber registration at Fina LRA is performed by Fina employees in organizational units of the Sector of register of accounts in regional centres i.e. branches, subsidiaries and business units (hereinafter referred to as: LRA officers). Exceptionally, subscriber registration is also performed by officers of the Central Fina RA. Registration tasks in the Fina RA Network is coordinated by the Central Fina RA which is the central communication point of the Fina RA Network. The list of current registration authorities of Fina LRA is available on the website http://www.fina.hr/finadigicert.

External sub-contracted RA Network is the Local Registration Authorities Network of the business entity with which Fina entered into an agreement on registration services provision for Fina CAs. Subscriber registration in External sub-contracted RAs shall be carried out by business entity employees with whom Fina concluded an agreement on registration services




provision. Tasks of Subscriber registration with the External sub-contracted RA shall be coordinated by the Central Fina RA.

The RA Network has to perform Subscriber registration for the issuance of certificates pursuant to the procedures described in this CPSNQC document.

Obligations and responsibilities of the Fina RA Network and the External sub-contracted RAs are listed under Section 9.6.2. of this CPSNQC document.

1.3.4. Subscribers

Fina PKI Subscribers shall be the persons entering into a Subscriber Agreement with Fina. Certification services under this CPSNQC document which Subscribers contract shall be services within the scope of issuance and management of life cycle of non-qualified certificates, as well as time-stamping services.

Fina PKI Subscribers may include:

• natural persons; and • business entities.

A special category of business entities within the scope of this document shall be TDU. Certificates for TDU shall be issued by Fina RDC-TDU 2015, and for all other certificate Subscribers by Fina RDC 2015. Time stamps for all business entities, including the TDU category, shall be issued by Fina QTSA 2015.

In order to use a certification service, the Subscribers should complete the registration procedure and submit their applications, as well as accept obligations and responsibilities referred to in Section 9.6.3. of this CPSNQC document. Within the registration procedure the Subscribers shall conclude the Subscriber Agreement with Fina. Should a Subscriber submit an application for a personal certificate, the agreement shall be signed and concluded by a natural person (signatory). In case of business certificates, the agreement shall be signed by an associated person (signatory) i.e. custodian, whereas an authorised person of the business entity shall sign and verify the agreement on behalf of the business entity it represents. TDU shall enter into a Subscriber Agreement with Fina, which shall act as the umbrella agreement. Such agreement shall be signed and verified by the TDI’s authorised person. During registration, each associated person (signatory) i.e. custodian within TDU shall enter into a separate agreement with Fina, which shall be signed by an associated person – signatory i.e. custodian, and which shall be signed and stamped by the TDU’s authorised person as a sign of verification.

Based on this Agreement, the submitted application and completed registration procedure, a specific Fina CA shall issue the required certificate. In case the Subscriber requested and contracted the time-stamping service, they shall be enabled to use the service contracted.



1.3.4.1. Subjects

Identification data on the Subject for whom the non-qualified certificate is issued shall be integrated into the certificate in the process of its creation. Subject may be a natural person, associated person, business entity and IT equipment (e.g. server, application, etc.). The Subject data shall form an integral part of the certificate.

In case when the Subject is IT equipment, the Subscriber shall assign the Certificate Custodian thereto. The Certificate Custodian is a natural person employed with the business entity or otherwise connected with the business entity, and authorised by the business entity to take over, use, safe-keep and take care of the private key and the pertaining certificate issued for the server, application or the Trusted List signature.

1.3.5. Relying parties

Relying Parties are natural persons or business entities to whom certificates are issued and who act based on a reasonable reliance on the certificate. The certificate enables the Relying Party to check the integrity and authenticity of electronically signed record or a subject identity.

Obligations and responsibilities of the Relying Party are listed in Section 9.6.4. of this CPSNQC document.

1.3.6. Other participants

Other participants in Fina PKI shall be legal persons who shall not provide or use certification services, but who shall participate in parts of the process related to certification services provision. This group of Fina PKI participants shall include manufacturers and distributors of hardware and software used in Fina PKI, manufacturers and distributors of smart cards, USB tokens, HSMs and other cryptographic devices, independent assessors and similar.

1.4. Certificate usage Based on certificate type purpose, permitted use and use restrictions the Relying Party shall decide whether a certain certificate is adequate and reliable for use and acceptance. The Relying Party shall be responsible for accepting and acting in reasonable reliance on the normalized certificate which has a certain safety level. When deciding on the acceptance of a certain security level normalization certificate, the Relying Party shall consider the following:

• legal requirements for counterparty identification, for example: confidentiality, legal admissibility of applicable electronic signature;

• all certificate data or the facts of which the Relying Party is aware, including the document Policy [36] and this CPSNQC document;

• transaction or communication economic value, if applicable;



• potential losses or damage which may be caused by incorrect identification, the loss

of trust or information secrecy during transactions or communication, • application of Croatian laws; • trading or exchanging customs or practices, especially of trade carried out through

trustworthy systems or by other computing system-based methods; • any adequacy or inadequacy indicator or other fact the Relying Party is aware of and

which refers to the Subject, the applied solution, communication or transaction; • recommended financial limit related to certificate security level.

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

Security level Scope of application Recommended financial limit

Standard This level shall be adequate for transactions of lower value and in environments in which the potential certificate misuse may cause minor damage or where the certificate misuse risk is 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 is medium.

up to HRK 80,000.00

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

up to HRK 400,000.00

Table 1.5 Security levels for certificates issued by Fina CAs

1.4.1. Appropriate use of Fina RDC 2015 and Fina RDC-TDU 2015 authentication NCP+ normalized certificates

Fina RDC 2015 and Fina RDC-TDU 2015 authentication NCP+ normalized certificates are in line with the Extended Normalized Certificate Policy (NCP+) of the standardization document HRN ETSI/EN 319 411-3 [12] and their use is limited to the support of electronic signature in accordance with the Electronic Signature Act [1], [2] and [3] on strong authentication and key encryption.

This Section encompasses the following types of certificates:

• Personal authentication N2 certificate (NCP+) issued to natural persons for personal needs. Natural person may use this certificate for business purposes as well, if in doing so it shall not be necessary to prove that they belong to a business entity by this certificate.

• Business authentication N2 certificate (NCP+) issued to associated persons in business entities which are not TDU for business purposes;

• TDU authentication N2 certificate (NCP+) issued to state officials and TDU employees for business purposes.



The given certificate types shall have medium security level and they shall be provided to Signatories exclusively on the SSCD Device, for example on adequate smart card or USB Token.

keyUsage extension shall be indicated as critical in those certificates and shall have the value set at digitalSignature and keyEncription.

1.4.1.1. Appropriate use of Fina RDC 2015 of authentication NCP normalized certificates

Fina RDC 2015 authentication NCP normalized certificates are in line with the Normalized Certificate Policy (NCP) of the standardization document HRN ETSI/EN 319 411-3 [12] and their use is limited to the support of electronic signature in accordance with the Electronic Signature Act [1], [2] and [3], on strong authentication and key encryption.


• Personal soft certificate (NCP) issued to natural persons for personal needs. Natural person may use this certificate for business purposes as well, if in doing so it shall not be necessary to prove that they belong to a business entity by this certificate.

• Business soft certificate (NCP) issued to associated persons in business entities which are not TDU for business purposes.

The given certificate types shall have standard security level and shall be issued with software key storage use.

keyUsage extension shall be indicated as critical in those certificates and shall have the value set at digitalSignature and keyEncription.

1.4.1.2. Appropriate use of Fina RDC 2015 authentication LCP lightweight certificates

Fina RDC 2015 authentication LCP lightweight certificates are in line with the Lightweight Certificate Policy (LCP) of the standardization document HRN ETSI/EN 319 411-3 [12] and their use is limited to the support of electronic signature in accordance with the Electronic Signature Act [1], [2] and [3], on strong authentication and key encryption.

This Section encompasses the business soft certificate (LCP). It shall be issued to associated persons in business entities which are not TDU for business purposes.

The given certificate type shall have standard security level and shall be issued with software key storage use.

keyUsage extension shall be indicated as critical and shall have the value set at digitalSignature and keyEncription.



1.4.1.3. Appropriate use of Fina RDC 2015 SSL normalized certificates

Fina RDC 2015 SSL server certificates are in line with NCP and NCP+ of the standardization document HRN ETSI/EN 319 411-3 [12] in accordance with the data from the list of certificate types encompassed by this Section given below. The same list includes the corresponding security levels.


• SSL level 2 certificate (NCP) of medium level security with software key storage use; • SSL level 3 certificate (NCP+) of medium level security with adequate HSM module

use.

Certificate types from the list which have SSL designation in their title shall be issued to web servers and shall be used for the establishment of SSL/TLS secure communication channel between the client and the server, where encryption and digital signature shall be used for the purpose of authenticating the Subjects in communication. Examples of use of such certificates are web services with strong authentication of users.

keyUsage extension of those certificates shall be indicated as critical and shall have the value set at digitalSignature and keyEncription.

1.4.1.4. Appropriate use of Fina RDC 2015 application normalized certificates

Fina RDC 2015 application certificates shall be in line with NCP and NCP+ of the standardization document HRN ETSI/EN 319 411-3 [12] in accordance with the data from the list of certificate types encompassed by this Section given below. The same list includes the corresponding security levels.


• Level 1 application certificate (NCP) of standard level security with software key storage use;

• Level 2 application certificate (NCP) of medium level security with software key storage use;

• Level 2 application certificate (NCP+) of medium level security with SSCD device use; • Level 3 application certificate (NCP+) of high level security with HSM module use.

The aforementioned certificate types shall be issued for applications or electronic services and their use shall be limited to the support of electronic signature in accordance with the Electronic Signature Act [1], [2] and [3], on strong authentication and key encryption.

keyUsage extension of those certificates shall be indicated as critical and shall have the value set at digitalSignature and keyEncription.



1.4.1.5. Appropriate use of Fina RDC 2015 certificates for Trusted list signing

Fina RDC 2015 certificates for Trusted list signing shall be in accordance with the rules of NCP+ of HRN ETSI/EN 319 411-3 [12] standard and ETSI TS 119 612 [14] standardization document and shall be issued to the Ministry of Economy.

This certificate type shall guarantee the electronic identity of the business entity having signed the Trusted list with the purpose of authenticity check and Trusted list integrity assurance.

This Section refers to one type of certificate:

• Certificate for signing Trusted List (NCP+).

These certificates shall be issued with SSCD Device use and shall have medium security level.

keyUsage extension shall be indicated as critical and shall have the value set at digitalSignature. This certificate type shall have an additional extKeyUsage extension which shall not be indicated as critical, and which shall have the value set at id-tsl-kp-tslSigning.

The certificate shall be used solely for Trusted list signing support.

1.4.1.6. Appropriate use of Fina RDC 2015 time-stamp certificates

Fina RDC 2015 time-stamp certificates shall be in line with NCP+ Certificate Policy of the standardization document HRN ETSI/EN 319 411-3 [12] and shall be issued to the business entity, including TDU exclusively for time stamping service signing support. This certificate type shall guarantee the electronic identity of the time stamping service.

This Section refers to the following type of certificate:

• Time-Stamp Certificate (NCP+)

These certificates shall be issued with HSM device use and shall have high security level.

keyUsage extension of those certificates shall be indicated as critical and shall have the value set at digitalSignature and nonRepudation. This certificate type shall have an additional extKeyUsage extension which shall be indicated as critical, and which shall have the value set at timeStamping.

1.4.1.7. Appropriate use of Fina RDC 2015 administrative NCP+ normalized certificates

Fina RDC 2015 administrative NCP+ normalized certificates shall be in line with NCP+ Certificate Policy of the standardization document HRN ETSI/EN 319 411-3 [12] and their use shall be limited solely to tasks within the Central Fina RA, Fina CAs and Fina QTSA.



This Section refers to the following type of certificate:

• Administrative N2 certificate (NCP+).

This certificate type shall have medium security level and shall be issued exclusively on SSCD device to authorised Fina employees for administration tasks within the Central Fina RA, Fina CA and Fina QTSA system.

1.4.2. Prohibited certificate uses

Every non-qualified certificate use differing from the uses described in Section1.4.1. of this CPSNQC document shall not be allowed.

1.5. CPSNQC document administration

1.5.1. Organization administering the CPSNQC document

Policy Management Authority Fina PMA shall be responsible for making and administering this CPSNQC document (see point 1.3. of this CPSNQC document).

1.5.2. Contact person

Contact details for administration and content of this CPSNQC document:

Mailing address:

FINA Financial and electronic services sector Office for e-Business policy management Koturaška cesta 43 10000 Zagreb Croatia

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

1.5.3. Person determining CPSNQC document suitability for the policy

CPSNQC document suitability for the Certificate Policy [36] shall be determined by Fina PMA.




1.5.4. CPSNQC approval procedures

For the CPSNQC document to be applied, it first has to be approved by Fina PMA. Fina PMA shall establish the effective date of the CPSNQC document.

Following amendments to legislation, list of binding standardization documents, business process regarding non-qualified certificates and time-stamps issuance, amendment to Certificate Policy Fina Root CA [35], Certificate Policy [36] or Qualified Time-Stamping Service Policy [37], which affect the procedures under this CPSNQC document, the CPSNQC document shall be revised by means of a compliance check with:

• new legislation; • new standardization documents; • new Certificate Policy Fina Root CA, Certificate Policy and new Certification Practice

Statement Fina Root CA; • new Qualified Time-Stamping Service Policy.

After the compliance has been carried out, Fina PMA shall approve the new CPSNQC document.

Effective date of the new CPSNQC document shall be established on the basis of assessment of certification system readiness for operation according to procedures stipulated in this document. Effective date of the new CPSNQC document version shall also mark the beginning of implementation of procedures described in it.

1.6. Definitions and acronyms

1.6.1. Definitions

DEFINITION MEANING

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

Advanced Electronic Signature

An electronic signature which reliably guarantees Signatory's identity and which:

• is linked exclusively to the Signatory; • unambiguously identifies the Signatory; • is created using devices that can be managed by the Signatory

itself and which are exclusively surveilled by them; • contains a direct link to the data to which it refers and in such a

way that it unambiguously enables insight into any modification to the original data.



DEFINITION MEANING

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.

Audit Log A set of records about incidents in the information system (log, audit log).

Authentication Subscriber identity check process, i.e. checking whether the Subscriber is exactly who it claims to be. Subscriber authentication shall be conducted with the aim of acquiring access to certain data or computer resources.

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 with a registered business, such as: • trades people; • attorneys; • notaries public; • public bailiffs etc.

CA-certificate A certificate in which (the same or any other) CA is given as the subject. CA certificate contains the title and CA public key.

CA private signing key CA private key and CA public key together make a CA key pair. CA private signing key is used for signing certificates issued by CA. The corresponding CA public key is entered into CA-certificate of that CA.

CA root certificate A CA-certificate issued and self-signed by the same CA to itself means that the Subject and the issuing CA are the same instance in the CA root certificate.

Central RA Central Registration Authority. It can register Subscribers, but it is primarily in charge of coordinating the entire RA Network.



DEFINITION MEANING

Certificate A confirmation in electronic form which: • names and identifies the Subject specified in the certificate; • contains the Subject public key; • specifies the validity period of the certificate; • has the meaning within the valid regulations and standards; • identifies the CA issuing the certificate; • is electronically signed by the CA.

Certificate Acceptance Procedures and actions carried out by the certificate applicant, on the basis of which it can be considered that the certificate is accepted by the signatory or the custodian. For example, it can be considered that the certificate is accepted in case the signatory or the custodian have signed the acceptance of the issued certificate or if CA did not receive any complaint from the Subscriber with the stipulated time period. The Subscriber may send a signed notice on certificate acceptance or a signed notice on refusal to accept the certificate, indicating the reason for certificate refusal and marking incorrect or incomplete fields in the certificate.

Certificate issuance after expiry

Issuing a new certificate whose parameters are equal to the parameters of the certificate to which the application refers, but with a new key, new certificate serial number, new validity period and a new signature by the same Fina CA. Depending on the certificate type and the deadline for certificate issuance, the newly issued certificate may have the same or modified Fina's internal serial number within the Distinguished Name.

Certificate issuance after revocation

Issuing a new certificate whose parameters are equal to the parameters of the certificate to which the application refers, but with a new key, new certificate serial number, new validity period, new signature by the same Fina CA and the modified Fina's internal serial number within the Distinguished Name.

Certificate Policy (CP) Named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements.

Certificate Profile A detailed list and description of certificate components and their values.

Certificate recovery Issuance of a new certificate whose parameters are equal to the parameters to which the application refers, but with a new key, new certificate serial number, new validity period and a new signature by the same Fina CA, and it shall be carried out prior to the deadline of the certificate renewal. Subscriber certificate whose recovery is requested shall be revoked, and the newly issued certificate shall have the same Fina's internal serial number within the Distinguished Name of the certificate, as well as the Subscriber certificate whose recovery is requested.



DEFINITION MEANING

Certificate renewal Certificate renewal in FINA PKI shall imply issuance of a new certificate whose parameters are equal to the parameters of the certificate to which the application refers, but with a new key, new certificate serial number, new validity period and a new signature by the same Fina CA, and it shall be carried out within the defined period prior to the certificate expiry date.

Certificate Reactivation The reactivation procedure concerning the suspended certificate once the reason for the suspension has been removed.

Certificate Revocation An action that makes a certificate irrevocably invalid from the moment of revocation onwards. The revocation becomes effective after a CRL containing an indication of the relevant certificate revocation is published.

Certificate Revocation List (CRL)

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

Certificate Suspension Procedure by which the certificate becomes temporarily invalid.

Certificate Validity Period A time period during which a certificate is considered valid. This time period begins with the time specified in the field "Valid from" and ends with the time in the field "Valid until".

Certification Authority (CA)

Authority trusted by one or more users to create and assign public-key certificates

Certification Practice Statement (CPS)

Document defining operational procedures of the Certificate Service Provider. Operational procedures defined by the Certification Practice Statement must be in accordance with the provisions defined in the Certificate Policy (CP) document.

Certification Service Provider (CSP)

Legal or natural person issuing certificates or providing other services in connection with electronic signatures. Other services connected with electronic signature may include time-stamping service, signature creation service, signature verification service, electronically signed records long-term retention service etc.

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

Custodian 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, use, store and take care of the private key and the pertaining certificate issued for the server, application and others. The Custodian shall submit a request for the certificate issuance, renewal, revocation, suspension or reactivation, and shall be the contact person for that certificate.

Decryption A process in cryptography transforming encrypted data into comprehensible data by using a decryption key and a decryption algorithm.



DEFINITION MEANING


Decryption Key Key used with decryption algorithm for data decryption for the purpose of obtaining intelligible data from encrypted data.

In case of asymmetrical cryptography, data decryption is performed by using the recipient's private key.

In case of electronic signature, summary decryption of signed data is performed with the signatory’s public key.

Digital signature Data added to a data set or data set cryptographic transformation which enables their recipient to prove the authenticity and integrity of the data set and which protects the data set from counterfeit, 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 signature A set of data in electronic form which are associated or logically connected with other data in electronic form, and which are used to identify the Signatory as well as to verify the authenticity of the signed electronic document.

Encryption Data modification cryptographic process during which information is made unintelligible to subjects not possessing the pertaining decryption key. In the process of decryption, this information may be made intelligible again by the use of a decryption key.

Encryption Key Key used with encryption algorithm for data encryption purposes.

In case of asymmetrical cryptography, data encryption is performed by using the recipient's public key.

In case of electronic signature, summary encryption is performed with the signatory’s private key.

External LRA Local Registration Authority within the competence of the External sub-contracted RA.

Fina LRA 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, business entities and state administration authorities, and which operates as the Trusted Third Party .

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

Fina RDC Register of Digital Certificates administered by Fina for digital certificate service provision and digital certificate life cycle management



DEFINITION MEANING


Key Generation A process creating a series of symbols which together make a cryptographic key.

Key pair Two mathematically linked cryptographic keys (private key and its pertaining public key) which shall have the following characteristics:

• one key from a key pair may be used for data encryption which may be decrypted solely by using another key from the same key pair and

• in case of knowing only one key it shall not be possible to disclose the other key (in reasonable time and with familiar technology).

LCP certificate LCP certificate, see the term "Lightweight certificate"

Lightweight certificate Certificate which provides a less demanding level of service quality in relation to certificates issued in accordance with the Certificate Policy on qualified certification in HRN ETSI/EN 319 411-2, LCP certificate.

Lightweight Directory Access Protocol (LDAP)

Application protocol which functions above the TCP/IP layer and is used for accessing and maintaining distributed connection , search and information modification services via an on-line network protocol.

LRA Officer Authorised employee of Fina's Local Registration Authority, that is, the documentation collecting Registration Authority, who shall identify, verify and register Subscribers.

Name (title) of the Subject

A certificate field containing a unique identifier of the Subject's name or title (field subject).

National PIN (OIB) system

Personal Identification Numbers (OIB) records' information system financed by the Ministry of Finance.

Normalized certificate A certificate providing the same quality as the one of certificates issued pursuant to the Certificate Practice Statement for Qualified Certificates described in HRN ETSI/EN 319 411-2, but without legal effect in terms of Directive 1999/93/EC and without the requirement to use Secure Signature Creation Device (Secure Signature Creation Device).

Object Identifier (OID) Identifier which represents a specific object. OID consists of numbers separated by points and listed in hierarchical order. Each number identifies a special node in the node tree, starting from the root of the tree.

Password A secret word or a sequence of characters entered by the Subscriber with the aim of gaining access to data or a certain system.

Public Key Infrastructure (PKI)

Architecture, organization, hardware, software, staff, rules, operational procedures collectively supporting the implementation and functioning of the cryptographic public key system for managing the digital certificate life-cycle.



DEFINITION MEANING


Public Directory A CA managed IT system which is used for on-line publication of documents and information concerning certificates, including information on certificate validity or revocation.

Public Key Publicly available cryptographic key which corresponds to the private key paired with it. Public key may be used for the verification of electronic signature or for data encryption.

Qualified certificate Electronic confirmation by which the qualified certificate service provider verifies the advanced electronic signature. Qualified certificate is issued by the qualified certificate service provider who meets the requirements stipulated in the Electronic Signature Act.

Person authorised for representation

A person who shall voluntarily conclude legal transaction or undertake another legal action on in someone else's behalf (representative). Representation authorisation may be based on law, statute, articles of association or legal person's rules, competent state body's act or power of attorney.

Policy Management Authority (PMA)

The body authorized and responsible for certification service rules creation, implementation and administration, for relevant documentation and procedures, as well as for the control of their implementation.

Private Key A cryptographic key confidentially kept by the subscriber, and corresponding to the paired public key. It is used for electronic signature creation or decryption of data encrypted by the corresponding public key.

RA Network The complete RA Network consisting of the Central Fina RA, Fina LRA and of external sub-contracted RAs with which Fina concluded an agreement on the registration services.



DEFINITION MEANING


Reasonable Reliance Reasonable reliance is deemed a decision by the Relying Party to rely on a certificate if at the time of reliance the Relying Party:

• used the certificate for the purposes prescribed in the CP under the circumstances in which the reliance is reasonable and in good faith, and under the circumstances known or which should be known to the Relying Party prior to relying on a certificate;

• checked whether the certificate has expired, has been revoked or suspended at the time of reliance, which should be ascertained by the Relying Party by checking the certificate's status on the basis of the last issued CRL as prescribed in the CP;

• checked whether all Subject's identity data in the certificate are properly displayed in the application which can be trusted;

• in the event of electronic signature, checked that the electronic signature was created by a private key corresponding to the public key in the certificate within the Certificate Validity Period

A Relying Party shall bear all the certificate reliance risks if it is aware of or has a reason to believe that there are facts that may cause a personal or business damage due to the certificate use.

Registration Authority (RA)

A legal entity or a natural person authorized by CA and in charge of identification and identity verification of the Applicant for the purpose of issuance, revocation, suspension or reactivation of the certificate, for the processing of requests and delivering certificates and devices to Subscribers.

Relying Party A certificate recipient acting on the basis of a reasonable reliance on the certificate. The certificate enables the Relying Party to check the integrity and authenticity of an electronically signed record, or to check the Subject's identity.

Signature Creation Device

Adequate IT equipment or software used by the Subscriber during electronic signature creation.

Secure Signature Creation Device (SSCD)

Signature Creation Device which shall ensure: • that the data for advanced electronic signature creation can appear

only once and that their security is accomplished; • that the data for advanced electronic signature creation cannot be

repeated and that the signature is protected from forgery while usi-ng the available technology;

• that the Subject can reliably protect the data for advanced electronic signature from being used by others.

Secure Signature Creation Device shall not change the data which are signed during the signature creation process or unable the Subject to view the data prior to the advanced signature creation process.



DEFINITION MEANING


Signatory A person in possession of the Signature Creation Device used for signing, who acts on their own behalf or on behalf of a natural person or a legal entity it represents.

State Administration Body (bodies) (TDU)

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

Subject Subject is the entity to which the certificate is issued. It can be a natural person, a natural person associated with the business entity (see the term: "Associated person"), server, application etc. the Subject data shall form an integral part of the certificate.

Subscriber A natural person or a business entity to which certification service provider provides services, i.e. with which the provider concludes the Subscriber Agreement.

Subscriber Agreement Agreement between a natural person, or business entity represented by the authorized person, and the Certification Service Provider, describing in detail the rights and the obligations of each party with respect to the certificate issued to the Subject.

Subscriber Roles Roles assumed by employees involved in certification business processes, which are not confidential roles. Responsibilities of those roles are described in the employee's job description.

Time-Stamp Token Electronically signed issuer's confirmation of the data contents to which it refers in a given period.

Trusted list The Trusted list of Certification Service Providers who shall be monitored/accredited by EU member states.

Trusted Roles Roles assigned to employees and which the security of Certificate Service Provider's work depends on. Trusted Roles and the corresponding responsibilities shall be clearly set out and described in the employee's job description.

Trustworthy System Information system or product implemented as hardware and/or software which shall create reliable and authentic records protected from modifications, and which shall additionally ensure technical and cryptographic security of the supported system (Trustworthy System).

Table 1.6 Definitions



1.6.2. Abbreviations

ABBREVIATION FULL NAME

CA Certification Authority

CP Certification Policy

CPS Certification Practice Statement

CPSNQC Certification Practice Statement for Non-Qualified Certificates

CPSQC Certification Practice Statement for Qualified Certificates

CPSROOT Certification Practice Statement Fina Root CA

CRL Certificate Revocation List

CSP Certification Service Provider

DN Distinguished Name

DNS Domain Name System DR Disaster Recovery

ISO International Standards Organization

LCP Lightweight Certificate Policy

LDAP Lightweight Directory Access Protocol

LRA Local Registration Authority

NCP Normalized Certificate Policy OCSP Online Certificate Status Protocol

OID Object Identifier

PIN Personal Identification Number PKCS Public Key Cryptography Standards

PKI Public Key Infrastructure

PMA Policy Management Authority

RA Registration Authority

SSCD Secure Signature Creation Device

SSL Secure Sockets Layer

SW Software

TDU State Administration Body (Bodies) TL Trusted list



ABBREVIATION FULL NAME

TLS Transport Layer Security

TSA Time-Stamping Authority

TSU Time-Stamping Unit

URL Uniform Resource Locator

UTC Coordinated Universal Time Table 1.7 Abbreviations



2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1. Repositories Fina PKI repositories 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 on the repositories. Fina PKI repositories from the domain of non-qualified certificates shall consist of the following repositories::

• Fina RDC 2015 repository, the content of which is operationally updated by Fina RDC 2015;

• Fina RDC-TDU 2015 repository, the content of which is operationally updated by Fina RDC-TDU 2015;

• Fina QTSA repository, the content of which is operationally updated by Fina QTSA.

Repositories can consist of a part available from websites and s part available via the LDAP server.

2.2. Publication of certification information

Fina PKI repositories publish documents and information on certification services provision as provided below.

2.2.1. FINA RDC 2015 repository

The following documents and information are published on websites:

• Current Certification Policy; • Older versions of Certification Policy documents; • Certification Services Terms and Conditions; • Valid certificate profiles description; • PKI services price list; • Certificate application templates; • Subscriber Agreement templates; • Templates for revocation, suspension and reactivation of certificates; • Power-of-attorney templates; • Fina RDC 2015 certificate information; • Unified CRL system Fina RDC 2015; • Information on legislation in the field of electronic signature and certification services; • Information on the existence of documents which are important for business

operation, but which cannot be fully published or which cannot be published at all due to content sensitivity or secrecy;



• Fina RAs/LRAs current locations; • Subscriber instructions; • Communications to Subscribers related to certification service provision; • Other Fina RDC 2015 operation-related information.

A public directory of certificates issued by Fina RDC 2015 can be searched on the repository’s website.

Content published on the website is available on http://www.fina.hr/finadigicert.

The following is published in the public directory structure:

• issued non-qualified certificates; • unified CRL and segmented CRL system Fina RDC 2015.

Information published in the public directory are available on ldap://rdc-ldap2.fina.hr.

Addresses of the Fina RDC 2015 repositories where CRL lists are published are noted in Section 4.10.1. of this CPSNQC document.

2.2.2. Fina RDC-TDU 2015 repository

The following documents and information are published on websites:

• Current Certification Policy; • Older versions of Certification Policy documents; • Certification Services Terms and Conditions; • Statement on Certification Services Provision; • Valid certificate profiles description; • PKI services price list; • Certificate application templates; • Subscriber Agreement templates; • Templates for revocation, suspension, reactivation or recovery of certificates; • Power-of-attorney templates; • Fina RDC-TDU 2015 certificate information; • Unified CRL system Fina RDC-TDU 2015; • Information on legislation in the field of electronic signature and certificate services for

TDU; • Information on the existence of documents which are important for business

operation, but which cannot be fully published or which cannot be published at all due to content sensitivity or secrecy;

• Fina RAs/LRAs current locations; • Subscriber instructions; • Communications to Subscribers related to certification service provision; • Other Fina RDC-TDU 2015 operation-related information.


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



Content published on the website is available on http://www.fina.hr/finadigicert.

The following is published in the public directory structure: • all issued normalized certificates; • unified CRL and segmented CRL system Fina RDC-TDU 2015.

Information published in the public directory are available on ldap://rdc-ldap2.fina.hr.

Addresses of the Fina RDC-TDU 2015 repositories where CRL lists are published are noted in Section 4.10. of this CPSNQC document.

Documents constituting a confidential part of internal certification rules shall not be publicly disclosed in Fina PKI repositories

2.2.3. Fina QTSA repository

Fina QTSA repository consists only of a part published on websites. Fina QTSA repository publishes the following documents and information:

• Current Qualified Time-Stamping Service Policy; • Older versions of Time-Stamping Service Policy documents; • Statement of the Provision of Time-Stamping Services; • Terms and conditions for time-stamping through the Fina’s time-stamping service; • Time-Stamping Service price list; • Application form for accessing Fina‘s Time-Stamping Service; • Information on the certificate for time-stamps signing; • Fina RAs/LRAs current locations; • Subscriber instructions; • Communications to Subscribers related to Time-Stamping Services; • Other Fina QTSA operation-related information.

Published content of the Fina QTSA repository is available on http://www.fina.hr/finadigicert.

Documents constituting a confidential part of internal certification rules shall not be publicly disclosed in Fina PKI repositories.

2.2.4. Contents Publication and Repository Management Procedures

Upon authorisation, documents publication on repository shall be performed by the authorised person in charge of content management of the on-line part of the repository.

Validity period and expiry of the Policy [36] are defined in Sections 9.10.1 and 9.10.2 of the Policy [36], and they are determined and approved by Fina PMA. Former versions of the documents remain published on the repository, with the time period indicating their validity.


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




Communications to Subscribers and information on legal acts shall be published after entry into force of legal acts in Fina PKI. Information and documents publication shall be approved, depending on the scope and type.

Information on Fina CAs certificates and on the certificate for time-stamps signing shall be published after they have been issued.

Documents on service provision terms and conditions, statements on time stamping services, Subscriber instructions, templates for applications, agreements and powers of attorney shall be approved by Fina PMA. These documents shall be published without prior announcement, and older versions of the documents shall be deleted from the repository.

Certificates shall be published automatically on the repository immediately after their issuance, provided that the Subscriber has previously approved their publication.

Following the issuance, CRL shall be published automatically by Fina CA in the public directory and the repository’s website.

Publication of the new version of pricelist shall be approved by the head of the e-Business Centre.

Communications and information to Subscribers may be published on the repository’s website even without Fina PMA consent, but Fina PMA must be notified in a timely manner on every publication of communications and information.

2.3. Time or frequency of publication

Policy [36], other documents and other information referred to in Sections 2.2.1 and 2.2.2 of this CPSNQC document shall be published when required, with a consent from Fina PMA.

The certificates shall be published in the public directory immediately following their issuance.

The frequency of publishing CRLs for certificates issued by Fina CAs is defined in Section 4.9.7. of the Policy.

On-line information on issued certificates status is available via Fina OCSP service described in Section 4.9.9. of this CPSNQC document.

2.4. Access controls on repositories

Information published on a repository are publicly available to all Fina PKI participants. Repository access is publicly available exclusively with the reading permission of the published content.

Repository access with the possibility to change the content shall have only authorised Fina employees pursuant to roles assigned to them. See Section 5.2 of this CPSNQC document for procedural controls in the Fina PKI system.



Fina shall ensure continuous repository availability in accordance with best business practices.



3. IDENTIFICATION AND AUTHENTICATION

Before issuing a certificate Fina shall perform timely Subject identification and authentication pursuant to procedures provided in this CPSNQC document.

Subject identification and authentication for Fina PKI shall be performed by the RA network consisting of the Fina RA network and network of a certain external sub-contracted RA. The Fina RA network shall consist of the Central Fina RA and Fina LRA. Employees authorised for registration in the RA network shall perform registration tasks pursuant to this CPSNQC document.

3.1. Naming

3.1.1. Types of names

Authentic Subject data shall be entered in the “Subject” field of each non-qualified certificate. One part of the “Subject” field shall contain the Subject's name and surname i.e. name. Moreover, the “Subject” field of personal certificates shall also contain the signatory’s place of residence, whereas in case of business certificates and business certificates for IT equipment the “Subject” field shall contain the name of the business entity’s registered office location. The “Subject” field in non-qualified certificates shall be aligned with the X.501 standard [33] and the IETF RFC 5280 recommendation [23].

The “Subject” field in personal and business non-qualified certificates shall contain name and surname of the person from the ID document accepted by Fina PKI, pursuant to Section 3.2.3.1. of this CPSNQC document, as well as an identifier in form of a multiple-component serial number ensuring uniqueness of the “Subject” field of those certificate types within Fina CA. The multiple-component serial number shall contain a country identifier, a unique 11-digit number and two numbers, pursuant to the description given in Section 3.1.4. of this CPSNQC document.

Server and application names entered in the “Subject” field of certificates issued for servers and applications and the content of the “Subject Alternative Name” field of certificates shall be in line with the IETF RFC 5322 recommendation [24]. The server/application names may be FQDN, the server IP address, or the application /service name or URL. During registration the Fina RA network shall verify ownership over the domain i.e. IP address area from the server/application name. If an e-mail address is entered in the “Subject Alternative Name” field, it does not have to be verified beforehand.



The “Subject” field in certificates issued for the Trusted list signature shall contain the abbreviated name and identifier of the ministry of economy as well as the name of authorised signatory role within the national operator.

In Fina RDC 2015 certificates, Fina RDC-TDU 2015 certificates and Fina RDC 2015 business certificates for IT equipment the “Subject” field shall contain the Subject's name and surname i.e. name, abbreviated name and business entity identifier. The abbreviated business entity name is identical to the abbreviated name entered in the competent register. If the competent register does not assign any abbreviated business entity name, full name of the business entity shall be entered in the “Subject” field. If the abbreviated business entity name or the full business entity name (in case the abbreviated name has not been assigned) contains more than 50 characters, it shall be additionally abbreviated to 50 characters by removing characters from the right, and such additionally abbreviated name shall be entered in the “Subject” field of certificates. Rules for creating business entity identifiers are described under Section 3.1.4 of this CPSNQC document. Should any data entered in the “Subject” field contain special characters or letters not belonging to the English of Croatian alphabet, such characters shall be replaced by the closest-resembling character in the English alphabet. Characters representing special characters of technical significance for the certification system shall be removed completely.

3.1.2. Need for names to be meaningful

Meaningful names in the “Subject” field identifying a natural person and a business entity, as well as meaningful names of places and countries shall be ensured by applying rules listed in Table 3.1.

Group certificate name Rule for element meaningfulness of the

Subject field Fina RDC 2015 personal non-qualified certificates

• commonName: Signatory’s Name and Surname

• localityName: Signatory’s Place of Residence • countryName: HR

Fina RDC 2015 business non-qualified certificates and

• commonName: Signatory’s Name and Surname

• localityName: Business entity registered office location

• organizationName: Business entity abbreviated name and identifier

• countryName: HR Fina RDC 2015 business non-qualified certificates for IT equipment

• localityName: Business entity registered office location

• organizationName: Business entity abbreviated name and identifier

• countryName: HR



Group certificate name Rule for element meaningfulness of the Subject field

FINA RDC-TDU 2015 non-qualified certificates

• commonName: Signatory’s Name and Surname • localityName: TDU registered office location • organizationalUnit: Level 2 sub-organizational TDU

unit (optional) • organizationalUnit: Level 1 sub-organizational TDU

unit (optional) • organizationName: TDU abbreviated name and

identifier • countryName: HR

Table 3.1 Rules for determining elements of the "Subject” field

When the IETF RFC 5322 [24] recommendation is used for certificate's attributes and fields value, meaningfulness of names shall not be verified.

3.1.3. Anonymity or pseudonymity of subscribers

Anonymity or pseudonymity of Subscribers are not supported.

3.1.4. Rules for interpreting various name forms

Interpretation of names according to the X.501 [33] standard for non-qualified certificates shall be performed according to Table 3.2.

Business non-qualified certificates

Field according to X.501 Fina RDC 2015 Fina RDC-TDU 2015 Explanation

Country (C)

HR HR Two-letter ISO country code, HR for Croatia.





Organization (O)

Business entity name and identifier

State administration body (TDU) name and identifier

Business entity or TDU name, two-letter ISO country code of the business entity or TDU's registered office, and an 11-digit number.

For business entities which have been assigned a personal identification number (OIB) and for TDU, the 11-digit number shall be the business entity’s or TDU's OIB.

For business entities with no OIB assigned to them and which are not registered in Croatia, the 11-digit number shall be the unique number assigned by Fina CA.

Organization Unit (OU)

Not applicable Sub-organizational Unit Name

Certificates issued by Fina RDC-TDU 2015 shall support two sub-organizational units within a TDU at most.

Locality (L)

Business entity registered office location

TDU registered office location

Business entity registered office location





Serial Number (SN)

- The associated person's (signatory) identifier

- Not used for business certificates for IT equipment

- The value of this field for the Trusted list signature certificates shall be the business entity's identifier.

The associated person's (signatory) identifier

The identifier is made of two-letter ISO code of the associated person's country of residence, an 11-digit number and two W and Z numbers representing designations having internal meaning for Fina PKI.

For signatories which have been assigned a personal identification number (OIB), the 11-digit number is the signatory’s OIB.

For signatories with no OIB assigned to them and which are not residents of Croatia, the 11-digit number shall be the unique number assigned by Fina CA.

Common Name (CN)

The associated person's business certificates: - The associated person's

(signatory) name and surname

Certificates for servers: - server FQDN; or - server IP address

Certificates for applications: - application name

For Trusted List Signing Certificates: - the name of the Trusted list

authorised signatory role within the ministry of economy.

The associated person's (signatory) name and surname

For associated persons: the associated person's (signatory) name and surname from an ID document.

For servers: Server FQDN or IP address.



Personal non-qualified certificates


Country (C)

HR Not applicable. Two-letter ISO country code, HR for Croatia.

Organization (O)

PERSONAL Not applicable. Personal certificate internal classification

Locality (L)

Natural person's place of residence

Not applicable. Natural person's (signatory) place of residence

Serial Number (SN)

Natural person’s identifier Not applicable. The identifier is made of two-letter ISO code of the natural person's country of residence, an 11-digit number and two W and Z numbers representing designations having internal meaning for Fina PKI.

For natural persons which have been assigned a personal identification number (OIB), the 11-digit number is the signatory’s OIB.

For natural persons with no OIB assigned to them and which are not residents of Croatia, the 11-digit number shall be the unique number assigned by Fina CA.

Common Name (CN)

Natural person's name and surname

Not applicable. Natural person's (signatory) name and surname from an ID document

Table 3.2 Name form interpretation according to X.501 standard

Name form interpretation according to IETF RFC 5322 recommendation [24] at Fina PKI to non-qualified certificates shall be applied to:

- for names in “Common Name” (CN) attribute where the Subject is a server, they shall be interpreted as server FQDN;



- for names in "Common Name" (CN) attribute where the Subject is an application, they

shall be interpreted as the application name; - for names in the „Subject Alternative Name" certificate extension which come in form of

an e-mail address, they shall be interpreted as the e-mail address.

The name form interpretation in Fina PKI according to X.501 standard [33] for CRL lists shall be performed according to Table 3.3.


Country (C)

HR HR Country of the certification service provider's registered office, Croatia

Organization (O)

Financijska agencija Financijska agencija Certification Service Provider

Organization Unit (OU)

Fina RDC 2015 Fina RDC-TDU 2015

Certification Authority Name

Common Name (CN)

CRLn CRLn

Segmented CRL List Identifier (CRLn) n denotes the number of segments of the segmented CRL list. (e.g. CRL1 is the first segment of the CRL list).

Table 3.3 Name form interpretation in Fina PKI according to X.501 standard for CRL

3.1.5. Uniqueness of names

Dataset in the “Subject” field distinguishes the Subject’s name (Distinguished Name, DN) according to the IETF RFC 5280 recommendation [23] and the X.501 standard [33].

The unique nature of distinguished name in Fina PKI non-qualified certificates shall be ensured by the IETF RFC 5280 recommendation [23] and the X.501 standard [33]:

• for signatories it shall be ensured with a serial number (SerialNumber attribute) in the distinguished name;

• for servers is shall be ensured by entering the unique server FQDN or IP address into the “Common Name” (CN) attribute of the distinguished certificate name;



• for applications is shall be ensured by entering the application name into the

“Common Name” (CN) attribute of the distinguished certificate name, which has to be unique within the same business entity;

• for Trusted list signing it shall be ensured with a serial number (SerialNumber attribute) in the distinguished name.

Fina CA shall independently control and assign the “SerialNumber” attribute value in the distinguished name in order to ensure uniqueness of Subject’s names.

3.1.6. Recognition, authentication and role of trademarks

No stipulations.

3.2. Initial identity validation

3.2.1. Method to prove possession of private key

3.2.1.1. Proving possession of NCP+ certificate private key

For the purpose of issuing normalized certificates which have to be issued on a SSCD device (NCP+ certificate types referred to in Section 1.1.2 of this CPSNQC document), the Subject's keys shall always be generated within the SSCD device. Fina supports the generation of keys for Signatories on the SSCD device at the Fina CA, Central Fina RA or Fina LRA location, or at the Subscriber’s location.

a) Keys on a SSCD device are generated by Fina CA or the Central Fina RA at its site

If Fina CA i.e. Central Fina RA is generating keys at its site, a procedure ensured by the Fina CMS system shall be used to prove that the Subject is in possession of the private key. This procedure shall be applied for issuing normalized NCP+ certificates for natural persons, associated persons in business entities and TDU, as well as administrative certificates.

An RA/LRA Official shall hand-over the SSCD device with generated keys and issued certificate to the Signatory, provided that the Signatory has been identified immediately before handover.

b) Keys on a SSCD device are generated by Fina LRA at its site

If Fina LRA is generating keys at its site, a procedure ensured by the Fina CMS system shall be used to prove that the Subject is in possession of the private key. This procedure shall be applied for issuing normalized NCP+ certificates for natural persons, associated persons in business entities and TDU, as well as administrative certificates.



RA/LRA officer SSCD device with associated keys and issued normalized NCP + certificate delivers the signatory with his previous immediate identification.

c) Keys are generated on a SSCD Device at Subscriber's site

If keys are generated at a Subscriber’s site, one of the following ways shall be used to prove that the Subject is in possession of the private key:

• The procedure using the Fina CMS system – used for issuing normalized NCP+ certificates for natural persons, associated persons in business entities and TDU, which are issued on a SSCD device. SSCD device shall be delivered to a previously registered Signatory, upon his/her immediate identification, with the use of authentication and secure online communication towards the SSCD device during the issuance of the certificate.

• The procedure including the use of CMS system of the external RA – used for issuing normalized NCP+ certificates for associated persons in business entities, which are issued on an SSCD device and registered by an external RA with its own CMS system. SSCD device shall be delivered to a previously registered Signatory, upon his/her immediate identification, with the use of authentication and secure online communication towards the SSCD device during the issuance of the certificate.

• The procedure including the use of another Fina CA web service for downloading certificates – used for issuing NCP+ level 2 application certificates, and for issuing all NCP+ level 3 certificates which are issued on the HSM device. Upon Custodian's immediate identification, activation code pairs used for authenticating the Custodian shall be delivered via reliable channels, and the procedure for initiating the issuance and download of certificates shall be performed by means of secure online communication.

3.2.1.2. Proving possession of NCP and LCP certificate private key

The Subject's keys for non-qualified NCP and LCP certificates shall be generated by Fina CA.

The Fina CMS system is used in this procedure and it shall be applied for the following certificate types:

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

Proving that the Subject possesses a private key is ensured by means of a procedure in which Fina CA generates and sends authorisation code and reference number for one-off log-in to Fina CMS system to the Signatory, i.e. Custodian, through separate channels. The Signatory, i.e. Custodian, may also take personally the authorisation code and the reference



number, upon immediate identification. The Signatory, i.e. Custodian, shall log-in to Fina CMS and initiate generation of a key pair which is generated on Fina's CMS system via the protected online communication. The Signatory, i.e. Custodian, shall enter the security password and download the protected PKCS#12 file with the private key and certificate.

3.2.2. Authentication of organization identity

In order to authenticate a business entity’s identity, an associated person shall provide correct and complete data on the business entity in the Certificate Application, which has to be signed and verified by an authorised representative.

Moreover, depending on laws and regulation in force in the Republic of Croatia regulating business entity's business activities, business entities shall submit the following documentation for the purpose of establishing the business entity’s legal form and identity:

• original or copy, along with the original for inspection, of the valid excerpt from the competent register, pursuant to laws and regulation of the Republic of Croatia so as to prove entry of business activities in the competent register or, if it has not been established that the business entity has to be registered with a register, an act i.e. another regulation on the basis of which the business entity is incorporated;

• the notification of the Croatian Bureau of Statistics concerning its classification according to the National Classification of Activities;

• a copy of an ID document of the natural person authorised for the business entity representation.

If a person designated as authorised representative in the certification of the power of attorney, which is used by the authorised representative for authorizing another person for signing the Subscriber Agreement for Business Entities and the Certificate Application for Business Certificates, is identified by the notary public, then, instead of an identification document copy of the authorised representative of the business entity, the power of attorney shall be submitted together with a copy of the authorised representative identification document.

Business entities organized outside the Republic of Croatia shall provide required certified translation of the current excerpt issued by the competent body in the country of their registered office.

After application data have been initially collected and submitted documentation has been received, the business entity shall be identified and its identity shall be authenticated as follows:

1. integrity, authenticity and validity of documentation used for registering business entity shall be checked;

2. it shall be checked whether the business entity is entered with the competent register if, according to regulation, it is required to be registered; if not, the competent body's decision or a regulation regarding the business entity’s incorporation shall be checked;



3. Fina RA/LRA shall further verify integrity of confidential data entered in the

application. The verification shall be performed by inspecting the national OIB system through the Fina RA application for data which can be reached from the OIB system;

4. authorization of the business entity authorised representative shall be checked, as well as correctness of their personal data. In case the authorised representative authorises a proxy, the power of attorney shall be verified on the basis of signature from the ID document of the natural person authorised for representation, as well as proxy data on the basis of the submitted copy of their ID document, upon prior verification of the person authorised to represent the business entity.

The business entity and identification of the authorised representative shall be registered in a one-off manner i.e. it shall not be repeated in case the business entity is already registered with the RA Network and is requesting a certificate for the next associated person. In such case, it shall only be verified whether the business entity authorised representative signing the application is stated in the competent register excerpt as an authorised representative and whether such person was registered in the initial Certificate Application and verified in a way described in Section 3.2.5. of this CPSNQC document.

Exceptionally, in case of change to business entity data contained in the certificate and listed in Section 3.1.1. of this CPSNQC document, the Signatory i.e. Custodian shall deliver proof of data change within legal time limit, and the RA Network Official shall enter the changed business entity data upon their prior verification.

In case of an already registered business entity on behalf of which a new Certificate Application or agreement is signed by an authorised representative not registered with Fina RA/LRA, when submitting the Certificate Application it shall be obligatory to submit a new and valid excerpt from the competent register confirming the authorised representative's authorization, as well as a copy of that authorised representative’s ID card. Verification procedure shall be the same as the initial identity verification procedure regarding the business entity. If the already registered authorised person is no longer listed in the new decision of the competent register, the same RA Network Officer shall delete such business entity in the Fina RA application from the registered authorised persons list.

In case of change to business entity data not contained in the certificate, but listed in Section 3.1.1. of this CPSNQC document, the Signatory i.e. Custodian shall deliver proof of data change when submitting the next application for certificate issuance or renewal, and the RA Network Official shall enter the changed business entity data upon their prior verification.

The business entity shall be liable for the accuracy and correctness of the data provided.

3.2.2.1. Authentication of business entity's identity upon provision of time-stamping services

In order to authenticate identity of a business entity requesting provision of time-stamping services, the Applicant shall state in the Time-Stamping Services Provision Application correct and complete data on the business entity and corresponding authentication



certificates, and such Application has to be signed and verified by an authorised representative.

The identity authentication procedure shall be performed by a Fina RA Network Officer based on inspection of the Fina RA application and, if applicable, the national OIB system. The Fina RA Officer shall compare the business entity data delivered in the Application with the data contained in the Fina RA application, and shall verify validity and interconnectivity of authentication certificates and the business entity. When accessing the time-stamping service, authentication certificates verified in such a way shall serve as confirmation of the service Subscriber’s identity.

3.2.3. Authentication of individual identity

Initial identification and authentication of the Signatory’s i.e. Custodian's identity shall be performed in Fina PKI by Fina RA/LRA or External RA using direct identification procedure and natural person identity authentication procedure pursuant to Section 3.2.3.2 of this CPSNQC document. Exceptionally, identification and authentication of the Signatory’s i.e. Custodian’s identity shall also be performed by the Central Fina RA.

Data in the application submitted by the Signatory i.e. Custodian have to contain name and surname, personal identification number (OIB), ID document number with the document validity date, nationality and phone or mobile phone number. If the Signatory i.e. Custodian requests the delivery of activation data by e-mail or in an SMS message, the application also has to contain data on the e-mail address and mobile phone number.

Additionally, with regard to Croatian citizens, data on the date and place of birth and the place of residence shall be collected. RA shall collect those additional data by inspecting the national OIB system, so the Signatory i.e. Custodian does not have to enter them in the application. The Fina RA/LRA Officer shall verify correctness of those data by comparing the data from the documentation delivered with the data from the national OIB system.

Natural persons of foreign nationality can be identified in two ways, depending on whether the foreign national has been assigned an OIB number in the Republic of Croatia. If the foreign national has been assigned an OIB number, they shall be identified the same way as Croatian nationals. If the foreign national has not been assigned an OIB number, they shall be identified by inspecting an acceptable ID document for a foreign national, defined in Section 3.2.3.1. of this CPSNQC document.

Additionally, with regard to Signatories i.e. Custodians of foreign nationality, data on the date and place of birth and the place of residence shall be collected. Fina RA/LRA shall collect those additional data and verify their correctness by comparing them in the documentation delivered.

The natural person in the capacity of a Signatory shall be immediately identified in cases of submitting certificate applications after their expiry and in cases of submitting certificate applications after their revocation.



Signatories of foreign nationality applying for issuance of a LCP certificate shall not be identified by means of direct identification. Such identification shall be performed by inspecting copies of two different ID documents for foreign nationals, defined in Section 3.2.3.1. of this CPSNQC document, as well as by means of a telephone enquiry on the officially registered business entity number with which the Signatory is associated. If the business entity representative confirm the Signatory's identity and their association with the business entity, it shall be considered that the Signatory has been identified indirectly pursuant to standards applicable for issuing LCP certificates.

Natural persons acting as the Signatory's proxy for the purpose of submitting applications and receiving SSCD devices with or without a private key on behalf of the Signatory shall be identified directly by inspecting an acceptable ID document referred to in Section 3.2.3.1 of this CPSNQC document. Additionally, the proxy has to deliver a status confirmation in form of a power of attorney signed by the Signatory on behalf of which he is receiving a SSCD device with or without a private key. In case the proxy receives the SSCD device with or without a private key on behalf of the Signatory – associated person of the business entity, the power of attorney has to be signed and verified with the business entity’s stamp.

Direct identification of Signatories shall not be obligatory during certificate renewal procedure, provided that the certificate is still valid and that is has not been suspended or revoked, as well as that Subject data contained in the certificate have not been altered in the meanwhile.

Natural persons acting as the Signatory’s proxy shall be allowed to submit applications in procedures of certificate renewal and recovery. Activation data shall be delivered solely to the Signatory in a secure way.

The RA Network Officer shall check all confidential data contained in the documents provided by the Signatory i.e. Custodian and he/she shall check the accuracy and the integrity of the Certificate Application information. The RA Network Officer shall sign the Certificate Application, thus verifying a successful and correct Signatory's i.e. Custodian's identification, and he/she shall enter the data or deliver them in a secure way to the Fina Subscriber registration system.

3.2.3.1. Eligible types of ID Documents

Certification Applicants (Signatories, Custodians or Proxies) shall prove their identity by a valid ID card or another public document containing the Applicant's photo and signature.

Foreign Applicants shall prove their identity by a valid travel document used to enter the Republic of Croatia. It is required to contact Fina PMA in order to obtain an authorization to prove a foreign Applicant's identity by other types of ID documents containing a photo, issued by the competent Croatian bodies.

Exceptionally, foreign citizens acting as signatories applying for LCP certificates can also be identified by other public document containing their photo, signature and personal data.



3.2.3.2. Direct identification procedure

Direct identification procedure shall be implemented in the physical presence of a natural person, based on an acceptable valid ID document proving their identity, described in Section 3.2.3.1. of this CPSNQC document. This procedure shall take place at a RA Network site or another site, in the presence of an authorised RA Network Officer, and can also be performed by another authorised employee of the Central Fina FA.

Signatory i.e. Custodian shall always be identified directly – upon submitting an application or receiving a SSCD device with or without a private key, except in case of issuing LCP certificates.

The direct identification procedure and authentication of natural person's identity shall be performed as follows:

• integrity, authenticity and validity of the ID document shall be verified; • integrity and correctness of natural person data contained in the Certificate

Application shall be verified; • natural person's identity shall be verified by way of direct face-to-face

identification on the basis of an ID document and comparison with the photo contained in the ID document;

• the ID document copy shall be compared with the original so as to verify authenticity of the copy;

• natural person data shall be verified for correctness, as well as their signature in the Certificate Application, by comparing them with the data and signature contained in the ID document. Additionally, data contained in the valid ID document shall be verified by inspecting the national OIB system, except for foreign nationals who have not been assigned an OIB number in the Republic of Croatia.

3.2.3.3. Indirect identification procedure

The Applicant's indirect identification procedure may be implemented only in the manner assuring the same security level of the Applicant's identity validation as the one assured in the direct physical identification procedure.

Electronic proof of the Applicant's authentication effected by direct physical identification of the Applicant shall be accepted as an indirect proof of the applicant's identity validation.

Electronic proof of the Applicant’s authentication signed by a private key corresponding to the public key in the certificate whose revocation or suspension has been requested shall not be accepted as an indirect proof of the Applicant’s identity validation, except in case of signing a request for Subscriber Agreement termination.

The Applicant's identification and authentication for the purpose of lightweight certificate issuance may be carried out by collecting stipulated documentation and verifying the data without direct identification of the Applicant.



3.2.3.4. Authentication of natural person’s identity upon provision of time-stamping

services

In order to authenticate identity of a natural person requesting provision of time-stamping services, the Applicant shall state in the Time-Stamping Services Provision Application correct and complete data on the natural person and corresponding authentication certificates, and such Application has to be signed by the natural person.

Natural person requesting provision of time-stamping services has to have a corresponding authentication certificate issued by Fina CA or has to be Custodian of the authentication certificate issued by Fina CA. A Fina RA Network Officer shall perform the identity authentication procedure by verifying interconnectivity of the natural person and the authentication certificated listed by the natural person in the Application. The Fina RA Officer shall compare the natural person data delivered in the Application with the data contained in the Fina RA application, and shall verify validity and interconnectivity of authentication certificates and the natural person. When accessing the time-stamping service, authentication certificates verified in such a way shall serve as confirmation of the service Subscriber’s identity.

3.2.4. Non-verified subscriber information

Non-verified Subscriber information shall be:

• TDU Sub-organization unit name; • phone numbers (except in case of a business entity applying for a lightweight

certificate).

The Signatory or the Custodian shall vouch for and it shall be held liable for the accuracy and the integrity of aforementioned data.

3.2.5. Validation of authority

Fina CA Business Certificate Application shall also be signed next to the seal by the business entity’s authorised representative, thus confirming the correctness of data contained in the Application.

The business entity’s authorised representative shall also sign next to the seal the Subscriber Agreement for Business Entities i.e. Agreement on Issuing Digital Certificates to TDU Employees.

If more people have been designated as individual and several representatives in a decision on business entity's registration with the competent register or another document in cases when the registration is not required, the Application and the Agreement shall be signed by any person authorised for such representation.



If more people have been designated as joint representatives, the Application and the Agreement shall be signed by authorised representatives pursuant to the decision or another document in cases when the registration is not required, or by one authorised representative along with a written consent of other joint representatives of the business entity.

The seal text has to be identical to the business entity name in full or abbreviated form as entered with the competent register, and certain differences in the seal may also be accepted as compared to the data from the documentation delivered if, by comparing the seal and the data from the documentation delivered, it can be established that it is one and the same business entity.

Fina CA Business Certificate Application i.e. the Agreement may also be signed next to the seal by a natural person authorised by the business entity on the basis of a special power of attorney for signing Certificate Applications i.e. Subscriber Agreements.

Natural person referred to in the previous paragraph shall deliver to the RA Network original or certified copy of the aforementioned special power of attorney.

Fina CA Business Certificate Application, revocation, suspension, reactivation or recovery request, Subscriber Agreement for Business Entities and Agreement on Issuing Digital Certificates to TDU Employees may be signed electronically with an advanced electronic signature pursuant to the aforementioned authorizations. In such case, the Signatory’s identity shall be established by an advanced electronic signature with a valid qualification certificate.

The RA Network shall establish based on the decision on entry in the competent register or another document if the registration is not required whether the person who signed the Application next to the seal is the authorised representative. If the Application or the Agreement is signed by the authorised person’s proxy, the RA Network shall establish from the corresponding power of attorney whether the person who signed the Application or the Agreement next to the seal is the same proxy from the power of attorney and if the power of attorney was signed by the authorised representative.

An RA Network Officer shall identify the authorised representative i.e. proxy of the business entity’s authorised representative who signed the Application or the Agreement next to the seal. Authorised representative i.e. their proxy shall be identified by checking the data contained in the documentation provided for the purpose of legal personality determination and identification referred to in Section 3.2.2. of this CPSNQC document and by comparing the data from the copy of an acceptable and valid ID document of the authorised representative i.e. their proxy. Types of acceptable ID documents are given in Section 3.2.3.1 of this CPSNQC document. Additionally, the national OIB system shall be inspected and all the data contained in the OIB system shall be verified by comparing them with the data contained in the ID document copy.



3.2.6. Criteria for interoperation

Non-qualified certificates issued by Fina RDC 2015 and Fina RDC-TDU 2015 for Subjects are intended for electronic business operations within and outside of Republic of Croatia, and they shall comply with international standards for their cross-border use. Non-qualified Signatory’s certificates shall meet the requirements of the provisions of the EU Electronic Signatures Directive [10].

3.3. Identification and authentication for re-key requests

3.3.1. Identification and authentication for routine re-key

In case of non-qualified certificate renewal, a new Subject’s key pair is generated and a new certificate issuance procedure is carried out pursuant to Section 4.7. of this CPSNQC document.

Identification and authentication of the Subscriber when renewing a certificate with generating a new key pair shall be carried out in two ways pursuant to Section 3.3.1.1. i.e. 3.3.1.2. of this CPSNQC document.

3.3.1.1. Identification and authentication for certificate re-key at Fina site

This procedure shall be carried out for the following certificate types:

• Personal Soft Certificate (NCP); • Business Soft Certificate (NCP); • Business Soft Certificate (LCP); • Application Certificate (NCP) Level 1, downloaded through the Fina CMS system.

Identification and authentication procedure in case of certificate renewal can be carried out at a RA Network site or by an LRA Agent’s visit to a Signatory i.e. Custodian site. Identification and authentication of the Signatory i.e. Custodian shall be carried out pursuant to the provisions of Section 3.2.3. of the CPSNQC document.

When applicable, the business entity’s identification and authentication shall be carried out pursuant to the provisions of Sections 3.2.2. and 3.2.5. of the CPSNQC document.

The business entity shall be verified by establishing whether there have been any changes to business entity data as compared with the data currently available to the Fina RA application. This verification shall be performed by inspecting data contained in the delivered Certificate Application and the national OIB system through the RA application, in case the business entity has been assigned an OIB number. If business entity data contained in the certificate differ from the valid data contained in the Fina RA application, the data shall be changed pursuant to Section 4.8. of this CPSNQC document.



If the Application was signed by an authorised representative who is not yet registered in the Fina RA application for that business entity, procedure described in Section 3.2.5 of this CPSNQC document shall be carried out.

3.3.1.2. Identification and authentication for certificate re-key under remote Fina CA supervision


• Personal Authentication N2 Certificate (NCP+); • Business Authentication N2 Certificate (NCP+); • Administrative N2 Certificate (NCP+); • TDU Authentication N2 Certificate (NCP+).

The Signatory shall be identified and authenticated by logging into the Fina CMS system with a valid non-qualified certificate for which the renewal procedure has been initiated. The log-in shall ensure a two-sided authenticated and secured SSL/TLS communication and remote supervision of the Fina CMS system.

Based on the verification of certificate for logging into the Fina CMs system, the remote identification and identity validation of the Signatory are performed, and the process for certificate renewal by means of generating a new key pair is initiated.

If the Signatory has been registered by an External RA and the Business Authentication N2 Certificate (NCP+) has initially been issued by using the CMS system of the External RA by using the Fina Proxy system, the Signatory’s identification and authentication shall be carried out by Signatory log-in into the CMS system of the External RA with a valid Business Authentication N2 Certificate (NCP+) for which the renewal procedure has been initiated. The log-in shall ensure a two-sided authenticated and secured SSL/TLS communication and remote supervision of the CMS system. Based on certificate verification used for logging into the CMS system, electronic Certificate Renewal Application signed electronically by the Signatory through the CMS system and on performed verification of data contained in that Application, remote identification and authentication of the Signatory has been performed in Fina and the certificate re-key process shall be initiated.

3.3.1.3. Identification and authentication for Subscriber certificate re-key

This procedure shall be carried out for all business certificates for IT equipment.

Identification and authentication procedure in case of renewal can be carried out at a RA Network site or by an LRA Agent’s visit to a Custodian site. Identification and authentication of the Custodian shall be carried out pursuant to the provisions of Section 3.2.3. of the CPSNQC document.

The business entity’s identification and authentication shall be carried out pursuant to the provisions of Sections 3.2.2. and 3.2.5. of the CPSNQC document.



The business entity shall be verified by establishing whether there have been any changes to business entity data as compared with the data currently available to the Fina RA application. This verification shall be performed by inspecting data contained in the delivered Certificate Application and the national OIB system through the RA application, in case the business entity has been assigned an OIB number. If business entity data contained in the certificate differ from the valid data contained in the Fina RA application, the data shall be changed pursuant to Section 4.8. of this CPSNQC document.

If the Application was signed by an authorised representative who is not yet registered in the Fina RA application for that business entity, procedure described in Section 3.2.5. of this CPSNQC document shall be carried out.

3.3.2. Identification and authentication for re-key after revocation

In case the Subscriber has a revoked or expired certificate, Subscriber identification and authentication shall be carried out in compliance with the procedure of initial identification referred to in Section 3.2. of this CPSNQC document. Upon positive identification, authentication and receipt of an accurate and complete Certificate Application, the Subscriber shall be issued a certificate whose parameters are equal to the parameters of the certificate to which the Application refers, but with a new key, new certificate serial number, new validity period and a new signature by the same Fina CA.

Internal Fina serial number shall be changed in all certificates containing an internal Fina serial number in the distinguished name in the newly issued certificate.

The Subscriber shall enter into a new Subscriber Agreement with Fina for the purpose of issuing a certificate upon its revocation.

3.4. Identification and authentication for revocation request

When receiving a certificate revocation or suspension request, Fina CA shall proceed with the Applicant's authentication in order to determine if the subject is actually the subject impersonated by the Applicant.

Certificate revocation and suspension are described in Section 4.9 of this CPSNQC document.

3.4.1. Personal delivery of the revocation request to the RA Network

The Applicant shall deliver an accurately and entirely filled in, and duly sealed and signed request form to the RA Network where a direct Applicant identification procedure may take place on the bases of his/her ID document, as described in Section 3.2.3.2. of this CPSNQC document.



The Applicant of a revocation request related to business certificates issued to natural persons, business certificates for IT equipment and TDU certificates may be the Signatory, or the Custodian, or the business entity authorised representative.

Applicant identification and authentication shall be effected by way of direct identification at RA Network on the basis of the Applicant's ID document.

3.4.2. Mail or courier delivery of the revocation request

The Applicant shall deliver an accurately and entirely filled in, and duly sealed and signed request form, accompanied by a copy of his/her ID document, to the RA Network, by mail or a courier.

The Applicant of a revocation request related to business certificates issued to natural persons, business certificates for IT equipment and TDU certificates may be the Signatory, or the Custodian, or the business entity authorised representative.

Applicant identification and authentication shall be effected at RA Network on the basis of the Applicant's ID document copy delivered together with the revocation request.

3.4.3. Revocation request by phone

Fina CA does not support the revocation procedure by phone.

The Applicant of the certificate revocation request may carry out only the suspension procedure by phone, whereas the revocation procedure may be carried out subsequently in one of the ways mentioned in Section 4.9.3. of this CPSNQC document.

3.4.4. Revocation request by telefax

Fina CA does not support the revocation procedure by telefax.

The Applicant of the certificate revocation request may carry out only the suspension procedure by telefax, whereas the revocation procedure may be carried out subsequently in one of the ways mentioned in Section 4.9.3. of this CPSNQC document.

3.4.5. Electronic delivery of the revocation request to e-mail address

The Applicant shall deliver the certificate form, accurately and entirely filled in and bearing the advanced electronic signature in the PAdES format, electronically at the following e-mail address: [email protected].




Applicant identification and authentication shall be effected by applying the indirect identification procedure referred to in Section 3.2.3.3. of this CPSNQC document, that is, by verifying and validating data in the Applicant’s advanced electronic signature.

3.4.6. Personal delivery of the suspension request to the RA Network

The Applicant shall deliver an accurately and entirely filled in, and duly sealed and signed request form to the RA Network where a direct Applicant identification procedure may take place on the bases of his/her ID document, as described in Section 3.2.3.2. of this CPSNQC document.

The Applicant of a suspension request related to business certificates issued to natural persons, business certificates for IT equipment and TDU certificates may be the Signatory, or the Custodian, or the business entity authorised representative.

Applicant identification and authentication shall be effected by way of direct identification at RA Network on the basis of the Applicant's ID document.

3.4.7. Mail or courier delivery of the suspension request

The Applicant shall deliver an accurately and entirely filled in, and duly sealed and signed suspension request form, accompanied by a copy of his/her ID document, to the RA Network, by mail or a courier.

The Applicant of a suspension request related to business certificates issued to natural persons, business certificates for IT equipment and TDU certificates may be the Signatory, or the Custodian, or the business entity authorised representative.

Applicant identification and authentication shall be effected at RA Network on the basis of the Applicant's ID document copy delivered together with the revocation request.

3.4.8. Suspension request by phone

Certificate suspension request by phone shall be delivered by calling the Fina Call Centre during working hours posted on the following web page http://www.fina.hr/finadigicert.

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

In case of the certificate suspension by phone, the authorised officer shall run the Applicant identification and authentication procedure based on enquiry and comparison of answers with the records stored in the RA system. Data checked during that process are the data related to the certificate to be suspended and Signatory/Custodian or authorised representative's personal details.




3.4.9. Suspension request by telefax

The Applicant shall deliver an accurately and entirely filled in, and duly sealed and signed suspension request form, accompanied by a copy of his/her ID document, to the following telefax number: +385 1 6304 081. Requests received by telefax during working hours of the Central Fina RA shall be processes the same day, whereas requests received outside Fina RA working hours shall be processed the following work day.

Applicant identification and authentication shall be effected on the basis of the Applicant's ID document copy delivered by telefax together with the revocation request.

3.4.10. Electronic delivery of the suspension request to e-mail address

The Applicant shall deliver the certificate form accurately and entirely filled in by e-mail at the following address: [email protected].

Applicant identification and authentication shall be effected by applying the indirect identification procedure referred to in Section 3.2.3.3. of this CPSNQC document, that is, by verifying and validating data in the Applicant’s advanced electronic signature.




4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1. Certificate Application

4.1.1. Who can submit a certificate application

A non-qualified certificate application may be submitted by natural persons or business entities, unless otherwise provided for in laws and acts adopted on the basis of such laws.

4.1.2. Enrolment process and responsibilities

Subscriber registration services with receiving non-qualified certificate applications, as well as Subject’s identification and authentication for Fina CA shall be provided by the Fina RA Network.

The External RA responsibility in case of default shall be regulated by the agreement entered into with Fina. Fina as a certification service provider shall be responsible towards participants in the PKI system for faults in operation of the RA Network.

The Fina RA Network and External RAs shall designate one or more people for performing identification and authentication pursuant to this CPSNQC document and Policy [36].

4.1.2.1. Certificate application process

A non-qualified certificate application may be intended solely for the purpose of issuing non-qualified certificates, or it can be combined with a qualified certificate application if both the non-qualified and the qualified certificate are issued simultaneously on the same SSCD device. The certificate application shall be complete, accurate and integral, as well as signed to confirm the authenticity of data contained in the application.

A personal non-qualified certificate application shall be signed by a natural person.

An application for non-qualified Fina RDC 2015 business certificates and Fina RDC 2015 business certificates for IT equipment shall be signed by an associated person or a Custodian, and a normalized Fina RDC-TDU 2015 certificate application shall be signed by an associated person. Such request shall be additionally verified by the business entity’s authorised representative with a seal and signature.

If more people have been designated as individual and several representatives in a decision on business entity's registration with the competent register or another document in cases when the registration is not required, the application shall be signed by any person authorised for such representation.



Rules for signing certificate applications by an authorised representative shall be the same for signing hard-copy applications and for signing soft-copy applications. These rules are listed in Section 3.2.5. of this CPSNQC document. A hard-copy application shall be additionally verified by the business entity's seal.

Upon receiving and verifying application data, the application shall also be signed by an RA Network Officer who shall, upon request, enter the date of its receipt. This shall confirm that the application submitted has been correctly filled in and signed, and that it has been accepted by the RA Network Officer.

In case a non-qualified certificate request is submitted electronically, the Fina service for downloading electronic application forms shall verify the application and ad a time stamp indicating the time of receiving the application. The RA Network Officer shall verify application data and validate all advanced electronic signatures contained in the application. Upon a positive verification of the electronic application, it shall be entered in the RA application.

Subscriber registration shall be carried out using a procedure described in Sections 3.2.2., 3.2.3. and 3.2.5. of this CPSNQC document.

4.1.2.2. Obligations and responsibilities in the certificate application process

Subscribers submitting a non-qualified certificate application shall enter into a Subscriber Agreement with Fina, whereby they shall accept the Certificate Policy [36] and Certification Services Terms and Conditions, thus also accepting responsibilities and obligations in the certificate application process.

Obligations and responsibilities of Subscribers in the certificate application process shall be as follows:

• the certificate application shall be filled in accurately and entirely as well as duly sealed and signed;

• the Subscriber registration and certificate issuance documentation provided shall be accurate and entire, as well as valid at the time of certificate application;

• the Signatory or the Custodian shall be placed under criminal and material liability for the accuracy and correctness of the personal data provided;

• the business entity authorised representative, or the business entity itself shall be placed under criminal and material liability for the accuracy and correctness of the data provided concerning himself/herself, the business entity, the associated person or other Subject;

• the Subscriber, the Signatory or the Custodian agree that Fina PKI may use and process the data in accordance with laws and representations and warranties contained in the certificate application and they acknowledge that Fina is authorised to keep the data during a legally stipulated period of at least 10 years from the last renewal of the certificate pertaining to the same Subject, or longer if provided so in Fina rules.



Obligations and responsibilities of the RA Network are listed in Section 9.6.2. of this CPSNQC document.

Obligations and responsibilities of Fina CA are listed in Section 9.6.1. of this CPSNQC document.

4.2. Certificate application processing

4.2.1. Performing identification and authentication functions

Subscriber identification and authentication shall be effected in accordance with Section 3 of this CPSNQC document.

When downloading a certificate application, an RA Network Officer shall perform the following procedure:

• after receiving the certificate application indicating issuance of a non-qualified certificate, the RA Network Officer shall inspect the received application pursuant to the procedures described in Sections 3.2.2., 3.2.3. and 3.2.5. of this CPSNQC document;

• in case the application has not been filled in accurately and entirely as well as duly sealed and signed (if applicable), the RA Network Officer shall reject such application and request an accurately and entirely filled in, signed and sealed application;

• in case of receiving an application for a business certificate, business certificate for IT subject or TDU certificate, the RA Network Officer shall verify whether the Applicant’s business entity and the Applicant itself are already registered. If there is no Applicant or business entity registration record in the Fina RA system, registration records shall be created through the Fina RA application and by inspecting the national OIB system (if applicable).

• in case of a personal non-qualified certificate, the Fina RA Network Officer shall verify whether the Applicant is already registered. If there is no Applicant registration record in the Fina RA system, registration records shall be created through the Fina RA application and by inspecting the national OIB system (if applicable);

• the Fina RA Network Officer shall set the Applicant status to “prepared”, thus indicating in the Fina RA application that the application has been approved. The Subject’s Distinguished Name (DN) shall also be generated in the process;

• Fina RA Network Official shall forward the approved application for further processing in Fina CA.

4.2.2. Approval or rejection of certificate applications

The approval or rejection of certificate applications is entrusted with an officer in the RA Network to which the Applicant has submitted the application. Should the RA Network Officer reject a certificate application, they shall notify the Applicant orally or in writing of rejecting



the certificate and of the reasons for such rejection. If the Applicant is physically present in RA Network, the Applicant shall be notified orally. If the Applicant is not physically present in RA Network, they shall be notified by phone or in e-mail message sent to the address indicated in the application.

A certificate application can be rejected for the following reasons:

• false data; • unduly signed or unduly sealed application or agreement; • incomplete or incorrect documentation delivered; • previous inappropriate procedures and default of Subscriber’s obligations; • statutory ban.

4.2.3. Time to process certificate applications

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

In case the Applicant fails to submit complete certificate application documentation within 60 days from the day of receiving the application, it shall be considered that they have given up on the certificate application.

4.3. Certificate issuance

Having received a certificate application and having performed the verification and approval processes listed in Section 4.2. and Sections 3.2.2., 3.2.3. and 3.2.5. of this CPSNQC document, Fina CA shall issue a certificate.

4.3.1. Fina CA actions during certificate issuance

4.3.1.1. Fina CA actions during NCP+ certificate issuance

Subscriber’ keys for individual types of NCP+ certificates during their issuance shall be generates pursuant to Section 6.1.1.3., 6.1.1.6. or 6.1.1.7. of this CPSNQC document.

Procedures described below in items a), b) and c) shall be applied for certificate types referred to in Section 6.1.1.3., item a). Only the procedure listed below in item a) shall be applied for the certificate types Certificate for signing the Trusted List (NCP+) and Administrative N2 certificate (NCP+).



a) Keys on a SSCD device are generated by Fina CA or the Central Fina RA at its

site

• upon receiving a request for issuing certificates from RA application, Fina CA, i.e. Central Fina RA shall generate and encrypt a separate PIN for each registered SSCD device in the Fina CMS system;

• the authorised person in Fina CA i.e. Central Fina RA shall generate and encrypt a separate PIN for each registered SSCD device in the Fina CMS system;

• authorised persons in Fina CA i.e. Central Fina RA shall generate keys in the SSCD device which has been linked with the Applicant and shall forward the Applicant’s public key for certification;

• Fina CA shall certify the public key by issuing a certificate of an appropriate profile to the Subscriber;

• the authorised person in Fina CA i.e. Central Fina RA shall enter the certificate in the corresponding SSCD device;

• the authorised person in Fina CA i.e. Central Fina RA shall forward the SSCD device with the corresponding key pair and the certificate via secure delivery to the RA Network;

• encrypted PIN of the SSCD device shall be sent to the Subscriber in an e-mail message or it shall be delivered to the Subscriber upon direct identification in the RA Network.


• Fina CA, i.e. Central Fina RA shall register SSCD devices in the Fina CMS system; • upon the delivery of a request, Fina LRA shall link the registered SSCD device with

the registered Signatory from the Registered Subscribers Database; • Fina LRA shall generate keys in the SSCD device which has been linked with the

Applicant and shall forward the Applicant’s public key for certification; • Fina CA shall certify the public key by issuing a certificate of an appropriate profile to

the Subscriber; • Fina LRA shall enter the certificate in the corresponding SSCD device; • the authorised person in Fina LRA shall deliver the SSCD device with the

corresponding key pair and the certificate to the Subscriber upon direct identification; • encrypted PIN of the SSCD device shall be sent to the Subscriber in an e-mail

message or it shall be delivered to the Subscriber upon direct identification in Fina LRA.

c) Keys are generated on a SSCD device at Subscriber's site

If keys are generated on a SSCD device under the supervision of Fina CA through the Fina CMS system, the following procedure shall apply:



• upon receiving the order for issuing a certificate from RA application, Fina CA shall

generate and encrypt a separate PIN for each registered SSCD device in the Fina CMS system;

• the authorised person in Fina CA shall generate and encrypt a separate PIN for each registered SSCD device in the Fina CMS system;

• encrypted PIN shall be sent to the Signatory in an e-mail message by the Fina CMS system;

• once the certification procedure has been initiated by the Signatory at a remote site by using the Fina CMS system, the Fina CMS system shall initiate generation of Subscriber’s keys in the Signatory’s SSCD device;

• Fina CMS system shall send the corresponding Subscriber’s public key in the PKCS#10 application format to Fina CA for the certificate issuance procedure;

• Fina CA shall certify the public key by issuing a certificate of an appropriate profile to the Subscriber and shall forward it to the CMS system through a secure channel;

• Fina CMS system shall enter the issued certificate in the Signatory’s SSCD device and shall initiate verification of the issued certificate;

• in case of a negative outcome of the issued certificate verification, the Applicant shall be urged to initiate or replace the SSCD device in the RA Network.

Exceptionally, if an External RA uses its own CMS system, the following procedure shall apply for the Business authentication N2 certificate (NCP+):

• once the certification procedure has been initiated by the Signatory, CMS system of the External RA shall initiate generation of Subscriber’s keys in the Signatory’s SSCD device;

• CMS system of the External RA shall create a PKCS#10 application format with a corresponding public key, which shall be additionally signed with electronic signature of the External RA;

• CMS system of the External RA shall deliver such PKCS#10 application format to Fina CA;

• upon receiving the PKCS#10 application, Fina CA shall verify validity of electronic signature signed by the External RA and the Signatory, thus also verifying the integrity and authenticity of application data;

• in case of an invalid signature of the External RA or the Signatory, or in case the Subscriber is not registered with the Fina RA system, the application shall be rejected;


• Fina CA shall forward the issued certificate to the CMS system of the External RA; • CMS system of the External RA shall enter the certificate in the Signatory’s SSCD

device and shall initiate verification of the issued certificate; • in case of a negative outcome of the issued certificate verification, External RA shall

urge the Applicant to initiate or replace the SSCD device.



The following procedure shall be used for NCP+ certificate types referred to in Section 6.1.1.3, items b), d) and e) and Section 6.1.1.6. of this CPSNQC document, together with using Fina’s second Fina CA web service for downloading certificates:

• upon receiving an order, Fina CA shall initiate preparatory activities for issuing a certificate from the order;

• Fina CA shall create a reference number and an authorization code for the Subject, which shall enable the Custodian remote downloading of certificates;

• if the Custodian has already been directly identified, an authorised employee in Fina CA shall send to the Custodian the authorization code and reference number for one-off long-in into another Fina CA web service for downloading certificates, whereby the data are sent via separate channels;

• if the Custodian has not been directly identified beforehand, Fina CA shall send in an encrypted e-mail message the reference number and the authorization code to the RA Network;

• an officer in the RA Network can personally, upon direct identification, deliver the aforementioned log-in data to the Custodian;

• once the Custodian has logged into another Fina CA web service for downloading certificates, the Custodian shall forward the application in the PKCS#10 format to Fina CA;

• Fina CA shall verify whether the PKCS#10 application is valid, whether the keys correspond with the requested certificate profile, and whether the Subject's private and public key have been paired up;

• in case an error is detected during verification, Fina CA shall notify the Custodian thereof;


• Fina CA shall enable the Custodian to download the issued certificate through the web service.

4.3.1.2. Fina CA actions during NCP and LCP certificate issuance

When issuing NCP or LCP certificates, Subscriber’s keys shall be generated for certain certificate types pursuant to Sections 6.1.1.4. and 6.1.1.5., respectively, of this CPSNQC document.

The following procedure shall apply for certificate types referred to in Section 6.1.1.4., items a), b), d), e) and Section 6.1.1.5.:

• upon receiving an order for certificate issuance from the RA application, Fina CA shall process data from the order through Fina CMS and perform certificate issuance preparatory activities;

• Fine CMS generates authentication data for logging; • Fina CMS system shall deliver authentication data to the Signatory, i.e. Custodian, via

separate channels;



• once the Signatory i.e. Custodian has initiated the certification procedure through the

Fina CMS system, the Fina CMS system shall generate Subscriber’s keys; • Fina CMS system shall send the corresponding public key in the PKCS#10

application format to Fina CA for the certificate issuance procedure; • Fina CA shall certify the public key by issuing a certificate of an appropriate profile to

the Signatory i.e. Custodian and shall forward it to the Fina CMS system through a secure channel;

• Fina CMS system shall generate a protected PKCS#12 file, which shall be downloaded by the Signatory, i.e. Custodian, through Fina CMS system.

The following procedure shall apply for certificate types referred to in Section 6.1.1.4., item c), together with using Fina’s alternative web service for downloading certificates:

• upon receiving a request for certificate issuance from the RA application, Fina CA shall initiate preparatory activities for issuing the certificate from the order;

• Fina CA shall create a reference number and an authorization code for the Subject, which shall enable the Custodian remote downloading of certificates;

• Fina CA shall send to the Custodian an authorisation code and a reference number for one-off log-in to alternative Fina CA web service for downloading certificates;

• the Custodian may also download the data for log-in in the RA Network, upon immediate identification;

• once the Custodian has logged into the alternative Fina CA web service for downloading certificates, the Custodian shall forward the application in the PKCS#10 format to Fina CA;

• Fina CA shall verify whether the PKCS#10 application is valid, whether the keys correspond with the requested certificate profile, and whether the Subject's private and public key have been paired up;

• in case an error is detected during verification, Fina CA shall notify the Custodian thereof;


• Fina CA shall enable the Custodian to download the issued certificate through the web service.

4.3.2. Notification to subscribers by the CA of issuance of certificate

The Signatory, or the Custodian, shall be notified by phone by an RA Network Officer of the possibility to download certificates. In case the RA Network Officer has failed to notify the Signatory, or the Custodian, by phone, the RA Network Officer shall notify the Signatory, or the Custodian, by e-mail. If the Signatory, or the Custodian, has failed to state his/her e-mail address in the Certificate Application, the Signatory, or the Custodian, shall be notified by post.



If the Signatory, or the Custodian, decides to download the certificate on-line, then he/she shall be notified by Fina CA of issuance of the certificate during on-line download procedure.

If the Signatory, or the Custodian, picks up the keys and the certificate on SSCD device in person in the RA Network, he/she shall be notified of issuance of the certificate by the RA Network Officer.

4.4. Certificate acceptance

4.4.1. Conduct constituting certificate acceptance

Pursuant to Section 3.2.1. of this CPSNQC document, after the Signatory or the Custodian has been notified of certificate issuance, the Signatory or the Custodian shall download the certificate in one of the following ways, depending on certificate type and manner of its issuance:

• in the RA Network, together with generated Subscriber keys on the SSCD device; • on-line through the Fina CMS system; • on-line through the CMS system of an External RA; • on-line via Fina’s alternative web service for downloading certificates.

Upon download, the Subscriber or the Custodian shall carry out the certificate content check pursuant to instructions received from Fina CA during or immediately after the certificate download. In case they do not accept any part of the certificate content, the Signatory or the Custodian shall reject acceptance and without delay notify Fina CA thereof to the e-mail address [email protected] or personally in RA Network, stating the reasons for rejecting the content. RA Network shall forward the notification to Fina CA. Upon receiving the notification, Fina CA shall revoke or suspend the certificate in question according to procedure described in Section 4.9. of this CPSNQC document. If the certificate is suspended, Fina shall, after identifying the Signatory or the Custodian within the period referred to in Section 4.9.16. and in line with Section 4.9.3. of this CPSNQC document, revoke the certificate and enable the re-issuance, including necessary modifications, based on the certificate application.

The Signatory or the Custodian shall be deemed to have accepted the certificate at the moment of its first use.

In the event that the Signatory or the Custodian fails to use or to reject the issued certificate within eight days of its download, the certificate shall be deemed accepted by the Signatory or the Custodian.

Instructions for registration and downloading certificates are available on the repository’s website referred to in Section 2.2. of this CPSNQC document. When receiving authentication data for certificate download, the Signatory or the Custodian shall also receive the corresponding instruction by e-mail.




4.4.2. Publication of the certificate by the CA

If the Signatory or the Custodian has authorised public disclosure of the certificate, Fina CA shall, immediately after its issuance, publish the Subscriber’s issued certificate in the Public directory of the corresponding repository referred to in Section 2.2. of this CPSNQC document.

4.4.3. Notification of certificate issuance by CA to other entities

It is implied that other parties are notified of certificate issuance by its publication in the Public directory. Fina CA shall not notify other parties of certificate issuance in any other way. If the Subscriber or the Custodian has not authorised public disclosure of the certificate, he/she shall assume the obligation to notify other parties of issuance, if necessary (e.g. by delivering the certificate to such other party).

4.5. Key pair and certificate usage

4.5.1. Subscriber private key and certificate usage

By signing the Subscriber Agreement, and in line with the rules contained in the Policy [36], business entities, the Signatory, or the Custodian undertake:

• to use the private key and pertaining certificate solely for the purposes provided for in the Policy [36];

• to use the private key and pertaining certificate solely during its validity period, that is, not to use the private key and the certificate after its expiry, revocation or suspension;

• to keep the private key and its copies (if their creation is permitted and possible) safe from theft, loss, modifications, compromise and unauthorised use from the moment of entering into Signatory’s, or Custodian's, sole possession;

• to keep the private key activation data safe at a protected place away from the private key;

• to inform Fina CA and request certificate suspension or revocation in the following cases: - the Signatory, or the IT equipment component private key has been lost, stolen or

possibly compromised; - the Signatory, or the Custodian, is not in the sole possession of the public key any

more, or there is a chance that the activation data have been compromised; - the certificate data are incorrect.

4.5.2. Relying party public key and certificate usage

The Relying Party that intends to rely on the certificate issued by Fina CA shall:



• use the certificate exclusively for the purposes provided for in Section 1.4. of this

CPSNQC document; • check the certificate expiry date; • check the certificate status regarding the certificate they intend to rely on by using

current and verified CRL list issued by the certificate-issuing Fina CA; • check the certificate according to the certification path validation procedures,

pursuant to document IETF RFC 5280 [23]; • check whether all Subject's identity data in the certificate are properly displayed in the

application which can be relied on; • in the event of electronic signature, check if the electronic signature was created by a

private key corresponding to the public key in the certificate within the Certificate Validity Period;

• in case of doubts regarding correctness of procedure used by the Relying Party’s application, based on the aforementioned provisions from this Section, the Relying Party shall:

- by viewing the certificate establish whether it has expired; - by viewing the valid and verified CRL list establish whether the certificate has

been revoked or suspended; - by viewing the certificate display check the certificate path.

The Relying Party shall not rely on an expired, revoked or suspended certificate. By relying on an expired, revoked or suspended certificate, the Relying Party shall lose all the warranties provided by Fina as a Certification Service Provider.

4.6. Certificate renewal

Pursuant to the provisions of Section 4.6. of the Policy [36], Fina CA shall renew certificates in such a way so as to generate a new key pair and issue a new certificate for the same Subject for each existing Subject whose certificate is about to expire. The new certificate DN shall be the same as the soon-to-expire-certificate DN. The non-qualified certificate re-key procedure is described in detail in Section 4.7. of this CPSNQC document.

Certificate renewal is described in Section 4.7. of this CPSNQC document.

4.6.1. Circumstance for certificate renewal

See Section 4.7.1.

4.6.2. Who may request renewal

See Section 4.7.2.



4.6.3. Processing certificate renewal requests

See Section 4.7.3.

4.6.4. Notification of new certificate issuance to subscriber

See Section 4.7.4.

4.6.5. Conduct constituting acceptance of a renewal certificate

See Section 4.7.5.

4.6.6. Publication of the renewal certificate by the CA

See Section 4.7.6.

4.6.7. Notification of certificate issuance by CA to other entities

See Section 4.7.7.

4.7. Certificate re-key

4.7.1. Circumstances for certificate re-key

Certificate re-key shall be performed if the following requirements are met:

• the certificate has not expired; • the certificate has not been revoked or suspended; • the certificate will expire within the period of less than 45 days; • Subject data and other attributes contained in the certificate are accurate and

complete at the moment of certificate renewal request.

Certificate recovery shall mean issuance of a new certificate whose parameters are equal to the parameters of the certificate to which the application refers, but with a new key, new certificate serial number, new validity period and a new signature by the same Fina CA, and it shall be carried out prior to deadline for certificate renewal. It shall be carried out in case of cryptographic device malfunction, deletion or destruction of the Subscriber's private key, or when the Subscriber, due to some other reason, is not able to use the private key which is connected with the public key in the certificate.



The prerequisite for submitting an application for certificate recovery is that the certificate is valid, i.e. it has not expired, it has not been revoked or suspended and that it is not necessary to change the Subscriber data in the certificate.

Furthermore, if the period in which it is possible to request certificate renewal has begun (45 days prior to the date of certificate expiry), it shall not be possible to request certificate recovery, but the Subscriber shall request certificate recovery through the certificate issuance application.

If the application for certificate recovery is justifiable, Fina CA shall revoke the certificate whose recovery is requested and it shall issue a new certificate with the same Distinguished Name (and the same Fina's internal serial number within the Distinguished Name).

Certificate issuance after expiry shall mean the issuance of a new certificate whose parameters are equal to the parameters of the certificate to which the application refers, but with a new key, new certificate serial number, new validity period and a new signature by the same Fina CA. Certificate issuance after expiry is not considered renewal of an existent expired certificate.

Depending on the deadline for carrying out the issuance of certificates on cryptographic devices, the newly issued certificate may have the same or modified Fina's internal serial number within the Distinguished Name, as the Subscriber certificate which has expired.

If the certificate is issued within 30 days following the certificate expiry, Fina's internal serial number within the Distinguished Name of the certificate remains the same if the certificate is issued on the same cryptographic device which contained the expired certificate. For that purpose, the Subscriber shall personally submit the cryptographic device which contains the expired certificate to the Fina LRA.

If the certificate is issued 30 days after the certificate expiration date, the serial number within the Distinguished Name of the certificate shall be modified.

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

In the procedure of issuing a certificate upon the expiry of a personal or business certificate issued on an SSCD device (Fina's e-card or USB token), the Applicant shall submit the same documents as for the initial certificate issuance.

If more than 30 days have passed from the certificate expiry, the Subscriber shall enter into a new Subscriber Agreement with Fina for issuing certificates after the expiry.

4.7.2. Who may request certification of a new public key

The Signatory, or the Custodian, shall be authorised to request renewal and recovery of pertaining certificates.



The certificate renewal or recovery request shall always be signed by the Signatory/Custodian.

The renewal or recovery request related to business certificates issued to natural persons, business certificates for IT equipment and TDU certificates shall be additionally be signed by the business entity authorised representative or TDU.

4.7.3. Processing certificate re-keying requests

4.7.3.1. Processing NCP+ certificate renewal or recovery requests

Certificate renewal and recovery procedures described below in items a), b) and e) shall be applied for certificate types referred to in Section 6.1.1.3., item a). Certificate renewal procedures described in c) shall be applied for certificate types referred to in Section 6.1.1.3., item a). Only the procedure listed below in item a) shall be applied for the certificate types Certificate for signing the Trusted List and Administrative N2 certificate (NCP+).

a) Keys on a SSCD device are generated by Fina CA or the Central Fina RA at its site

• the Signatory shall submit the certificate renewal or recovery request to RA Network or on other specified location, subject to proper identification in accordance with Section 3.3.1.1. of this CPSNQC document;

• an RA Network Officer shall accept or reject the request pursuant to certificate applications approval or rejection procedures referred to in Section 4.2.2. of this CPSNQC document;

• Fina CA shall issue certificates pursuant to the procedure described in Section 4.3.1.1., item a) of this CPSNQC document.

• Fina CA shall revoke the old certificate.


• the Signatory shall submit the certificate renewal or recovery request to RA Network or on other specified location, subject to proper identification in accordance with Section 3.3.1.1. of this CPSNQC document;

• an RA Network Officer shall accept or reject the request pursuant to certificate applications approval or rejection procedures referred to in Section 4.2.2. of this CPSNQC document;

• Fina LRA shall perform operations pursuant to the procedure described in Section 4.3.1.1., item b) of this CPSNQC document.




c) Keys are generated on a SSCD device at Subscriber's site

If keys are generated on a SSCD device under the supervision of Fina CA through the Fina CMS system, the following procedure shall apply to certificate renewal:

• the Signatory shall connect with the Fina CMS system with a valid certificate on a corresponding SSCD device and activation data, and a secure SSL/TLS communication shall be established with two-sided authentication. By remote work through the CMS web interface the Signatory shall gain insight into current data regarding their valid certificate, as well as into data regarding which certificate can be renewed (in case they possess more than one certificates);

• in the Fina CMS system the Signatory shall check the valid certificate data, that shall also be contained in the new certificate;

• if the valid certificate data are correct and complete at the moment of initiating certificate renewal, the Signatory can request its renewal by confirming sending of the certificate renewal request through the Fina CMS system. On that occasion, the Signatory shall sign electronically the created request with the currently valid certificate, and the Fina CMS shall process it, verify it and save it. In case the valid certificate data are not correct, the Signatory shall notify Fina CA of changes within the certificate;

• if the request’s electronic signature has been verified successfully and the request data have been checked successfully, based on the request the Fina CMS application shall initiate generation of a new key pair on the Subscriber’s SSCD device, and a signed PKCS#10 application shall be generated at a Subscriber’s site with the newly generated public key, which shall be forwarded to Fina CA for certification via the secure communication established.

• if the request’s electronic signature has not been verified successfully, Fina CMS shall report an error, and the Signatory shall act in line with the initial certificate issuance procedure.

• Fina CMS system shall send the corresponding public key in the PKCS#10 application format to Fina CA for the certificate issuance procedure;

• Fina CA shall certify the public key by issuing a certificate of an appropriate profile to the Subscriber and shall forward it to the CMS system through a secure channel;

• Fina CMS system shall enter the issued certificate in the Signatory’s SSCD device and shall initiate verification of the issued certificate;

• in case of a negative outcome of the issued certificate verification, the Applicant shall be urged to initiate or replace the SSCD device in the RA Network;

• Fina CA shall revoke the old certificate. Exceptionally, if an External RA uses its own CMS system, the following procedure shall apply for the Business authentication N2 certificate (NCP+):

• once the certificate renewal procedure has been initiated by the Signatory, CMS system of the External RA shall initiate the keys generation procedure in the Signatory’s SSCD device;



• CMS system of the External RA shall create a PKCS#10 application format with a

corresponding public key, which shall be additionally signed with electronic signature of the External RA;

• CMS system of the External RA shall deliver such PKCS#10 application format to the Fina PKI Proxy system;

• upon receiving the PKCS#10 application, Fina PKI Proxy shall verify validity of electronic signature signed by the External RA and the Signatory, thus also verifying the integrity and authenticity of application data. In addition, Fina PKI Proxy shall check whether the Subscriber is registered with the Fina RA system;

• in case of an invalid signature of the External RA or the Signatory, or in case the Subscriber is not registered with the Fina RA system, the application shall be rejected;


• Fina CA shall forward the issued certificate through the Fina PKI Proxy service to the CMS system of the External RA;

• CMS system of the External RA shall enter the certificate in the Signatory’s SSCD device and shall initiate verification of the issued certificate;

• in case of a negative outcome of the issued certificate verification, External RA shall urge the Applicant to initiate or replace the SSCD device.

Regarding renewal or recovery of NCP+ type certificates referred to in Section 6.1.1.3., items b), d) and Section 6.1.1.6. of this CPSNQC document, together with using Fina’s alternative web service for downloading certificates, the procedure identical to the initial certificate issuance procedure regarding this type of certificates referred to in Section 4.3.1.1. of this CPSNQC document shall be used.

The recovery process for all types of NCP+ certificates shall be performed exclusively in the manner described in items a) and b) of this Section. Once the certificate has been issued, during recovery Fina CA shall revoke the certificate requested for recovery.

4.7.3.2. Processing NCP and LCP certificate renewal or recovery requests

When issuing NCP or LCP certificates, Subscriber’s keys shall be generated for certain certificate types pursuant to Sections 6.1.1.4. and 6.1.1.5., respectively, of this CPSNQC document.

The following procedure shall apply for certificate types referred to in Section 6.1.1.4., items a), b), d), e) and Section 6.1.1.5.:

• The Signatory, or the Custodian, shall log into Fina CMS with authentication certificate for which they intend to initiate the renewal procedure, whereby a secure SSL/TLS communication with two-sided authentication shall be established. By remote work through the CMS web interface the Signatory, or the Custodian, shall gain insight into current data regarding their valid certificate, as well as into data



regarding which certificate can be renewed (in case they possess or are custodians of more than one certificates);

• The Signatory, or the Custodian, shall check the valid certificate data, that shall also be contained in the new certificate;

• if the valid certificate data are correct and complete at the moment of initiating certificate renewal, the Signatory, or the Custodian, can request its renewal by confirming sending of the certificate renewal request through the Fina CMS system. On that occasion, the request created shall be signed electronically with the currently valid certificate, and the Fina CMS shall process it, verify it and save it. In case the valid certificate data are not correct, the Signatory, or the Custodian, shall notify Fina CA of changes within the certificate;

• if the request’s electronic signature has been verified successfully and the request data have been checked successfully, based on the request the Fina CMS system shall initiate generation of a new key pair, create a signed PKCS#10 application with the newly generated public key, which shall be forwarded to Fina CA for certification via the secure communication established.

• Fina CA shall certify the delivered public key, and the issued certificate shall be forwarded to the Fina CMS system via the internal secure communication.

• Fina CMS system shall create a protected PKCS#12 file, which is downloaded through the Fina CMS system by the Signatory, i.e. Custodian, who then saves it on his//her computer;


In case of certificate type referred to in Section 6.1.1.4., item c), the Custodian shall, by using Fina’s alternative web service for downloading certificates, perform the renewal procedure, which is identical to the initial certificate issuance procedure referred to in Section 4.3.1.2. of this CPSNQC document.

In case of all NCP and LCP certificate types, the certificate recovery procedure shall be identical to the initial certificate issuance procedure referred to in Section 4.3.1.2. of this CPSNQC document. Once the certificate has been issued, during recovery Fina CA shall revoke the certificate requested for recovery.


Central Fina RA or an External RA shall in writing notify the Signatory, or the Custodian, of the upcoming certificate expiry and invite them to renew the certificate and perform the re-key during the month immediately preceding the month of the certificate expiry. Signatories, or Custodians, who have listed their e-mail address in the certification application shall be notified by e-mail, whereas other Signatories and Custodians shall be notified by mail.



4.7.5. Conduct constituting acceptance of a re-keyed certificate

Re-key acceptance shall be carried out in accordance with Section 4.4.1. of this CPSNQC document.

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

A re-keyed certificate shall be published as described in Section 4.4.2. of this CPSNQC document.

4.7.7. Notification of re-keyed certificate by the CA to other entities

Fina CA shall notify other parties of a re-keyed certificate in accordance with Section 4.4.3. of this CPSNQC document.

4.8. Certificate modification

Signatories and Custodians shall inform Fina PKI on the modification of data contained in the certificate within two days, as stipulated by the Electronic Signature Act [1], [2] and [3], and request certificate data modification.

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

4.8.1. Circumstances for certificate modification

If the certificate has been issued as a personal certificate, business certificate or certificate for TDU, the reasons for certificate modification shall be changes of:

• Signatory's name or surname; • name of the Trusted list authorised signatory role; • business entity name; • business entity identifier; • data on the place of residence of the natural person or the registered office of the

business entity; • e-mail addresses, for certificates containing e-mail address in the Subject alternative

name extension of the certificate. If the certificate has been issued as a business certificate for IT equipment, the reasons of certificate modification shall be the changes of:

• server or application name; • business entity name; • business entity registered office location data;



• e-mail addresses, for certificates containing e-mail address in the Subject alternative

name extension of the certificate; • certificate extension content.

4.8.2. Who may request certificate modification

Certificate modification may be requested by the Signatory, or the Custodian, and the request shall be signed pursuant to the signing rules listed in Section 3.2.5.

4.8.3. Processing certificate modification requests

Signatory, or the Custodian, shall submit a certificate modification request to the RA Network and shall deliver the part of the documents referred to in Section 3.2. of this CPSNQC document, proving the newly occurred change.

Certificate modifications shall be carried out by Fina CA by revocation of the existing certificate and by the issuance of a new one with re-key and modified certificate data. The old certificate shall be revoked pursuant to Section 4.9. of this CPSNQC document, and the new certificate shall be issued pursuant to Sections 4.2., 4.3. and 4.4. of this CPSNQC document.


When issuing certificates in the certificate modification process, Fina CA shall perform the same procedure as for notification, as described in Section 4.3.2. of this CPSNQC document.

4.8.5. Conduct constituting acceptance of the modified certificate

Modified certificates shall be accepted in accordance with Section 4.4.1. of this CPSNQC document.

4.8.6. Publication of the modified certificate by the CA

Modified certificates shall be published by Fina CA pursuant to Section 4.4.2. of this CPSNQC document.

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

Other parties shall be notified by Fina CA of the modified certificate issuance as described in Section 4.4.3. of this CPSNQC document.



4.9. Certificate revocation and suspension

4.9.1. Circumstances for revocation

Fina CA shall revoke certificates for the following reasons:

• if a piece of information in the certificate becomes inaccurate; • if there is a reasonable doubt about private key being compromised or if the private

key or a device where the key is stored has actually been compromised; • in case of loss or permanent unavailability of the private key; • if there is a reasonable doubt about private key or activation data not being in the sole

possession of the Signatory, or the Custodian any more, or in the event of theft of the private key or the activation data;

• if the relationship underlying the issuance of the certificate to the Signatory, whereby they shall act as an associated person on behalf of a natural or legal person, ends;

• if the Subscriber for any reason whatsoever does not need to use the certificate any more;

• if Fina CA considers that the certificate has not been issued in accordance with the request or provisions contain in this CPSNQC document;

• in case of Subscriber Agreement termination by the Subscriber.

Should the Subscriber or the Custodian fail to meet ther obligations under this CPSNQC document and signed agreements, Fina CA shall revoke the certificate at the request of the Head of the e-Business Centre or at the request of Fina CA. Fina CA may also revoke a certificate based on an authenticated notification by a third party, upon prior check of the information, or based on an authenticated official notification by a competent body.

4.9.2. Who can request revocation

The Signatories shall be authorised to submit the corresponding personal certificates revocation requests.

The revocation request related to business certificates issued to natural persons, business certificates for IT equipment and TDU certificates may be submitted by the Signatory, the Custodian or the business entity authorised representative, but it shall always be signed by the business entity authorised representative.

RA Network may file the certificate revocation request on its own behalf.

Fina CA may request revocation of any issued certificate upon approval of the Head of the e-Business Centre or Fina PMA.

Fina CA shall notify in writing the corresponding Signatory or the Custodian and, if applicable, the Subscriber of the performed certificate revocation. Signatories, Custodians



and Subscribers who have listed their e-mail address in the certification application shall be notified by e-mail, whereas other Signatories, Custodians and Subscribers shall be notified by mail.

Notification of revocation performed based on the competent body's authenticated official notification shall be sent by registered mail to the Subscriber and to the competent body which has requested revocation.

4.9.3. Procedure for revocation request

A certificate revocation request shall be in form of the certificate revocation, suspension, reactivation or recovery request, which is available on Fina PKI repository’s website referred to in Section 2.2. of this CPSNQC document. Immediately upon occurrence of any reason for revocation listed in Section 4.9.1. of this CPSNQC document, the certificate revocation request shall be filled in accurately and entirely, as well as signed and submitted as soon as possible to Fina PKI by one of the following methods:

• by personal delivery to RA Network during office hours:

A filled-in and personally signed certificate revocation request, with direct identification of the Applicant according to the procedure described in Section 3.4.1. of this CPSNQC document, shall be delivered to an RA Network Officer.

• by mail or courier at RA Network address:

A filled-in and personally signed certificate revocation request, with direct identification of the Applicant according to the procedure described in Section 3.4.2. of this CPSNQC document, shall be delivered by mail or courier to RA Network.

• electronically, to the e-mail address:

A filled-in certificate revocation request, which the Applicant has signed with an advanced electronic signature, shall be delivered and the Applicant shall be identified according to the procedure described in Section 3.4.5. If the Applicant is signing the request with a private key corresponding to the certificate which is being revoked, the signature shall be accepted as valid only in cases of Subscriber Agreement termination by the Subscriber and when the revocation was due to end of the relationship underlying the issuance of the certificate to the Signatory, whereby they shall act as an associated person on behalf of a natural or legal person If the Applicant submits a duly signed, but incomplete request, and if the certificate cannot be revoked based on data contained in the request, instead of the requested revocation Fina CA shall suspend the certificate pursuant to Section 4.9.15 of this CPSNQC document, provided that the request contains enough data required for suspension.



When receiving revocation requests by way of personal delivery, an RA Network Officer shall perform the following procedure:

• the RA Network Officer shall check integrity, authenticity and correctness of the request and data contained therein;

• if the request and the data contained therein are not integral, authentic and correct, the RA Network Officer shall reject the request and urge the Applicant to fill in the request completely, authentically and correctly;

• the RA Network Officer shall identify and authenticate the Applicant pursuant to Section 3.4.1. of this CPSNQC document;

• if the Applicant’s verification was not successful, the RA Network Officer shall reject the certificate revocation request;

• the RA Network Officer shall forward the revocation request to Fina CA for revocation procedure.

When receiving revocation requests by mail or courier at RA Network address:


• if the request and the data contained therein are not integral, authentic and correct, the RA Network Officer shall reject the request and notify the Applicant of the reasons for rejecting it;


• if the Applicant’s verification was not successful, the RA Network Officer shall reject the certificate revocation request and notify the Applicant thereof;

• the RA Network Officer shall forward the revocation request to Fina CA for revocation procedure.

Fina CA procedure when receiving revocation requests by an RA Network Officer:

• based on a revocation request, an authorised person of Fina CA or the Central Fina RA shall revoke the certificate by changing its status and publishing a new CRL list containing the certificate revocation information;

• Fina CA shall notify the Signatory, Custodian or authorised representative, if applicable, of the revocation performed.

If Fina CA has received a certificate revocation request by e-mail sent directly by the Applicant or an External RA, Fina CA shall perform the following procedure:

• an authorised person of Fina CA or the Central Fina CA shall verify an advanced electronic signature contained in the revocation request;

• the authorised person of Fina CA or the Central Fina CA shall verify correctness and integrity of data contained on the revocation request;

• the authorised person of Fina CA or the Central Fina RA shall revoke the certificate and publish a new CRL list containing the certificate revocation information;



• if the Applicant submits an incomplete request, the certificate shall be suspended

based on the request, pursuant to Section 4.9.15. of this CPSNQC document, provided that the request contains enough data for performing suspension, and the Applicant shall be notified by e-mail of the error and asked to re-submit the certificate revocation request;

• Fina CA shall notify by e-mail the Signatory, Custodian or authorised representative, if applicable, of the revocation performed.

4.9.4. Revocation request grace period

The Applicants of certificate revocation requests referred to in Section 4.9.2. of this CPSNQC document shall submit the certificate revocation request as soon as reasonably practicable from the occurrence of the reasons for revocation laid down in Section 4.9.1. of this CPSNQC document.

4.9.5. Time within which CA must process revocation request

Fina CA shall revoke the certificate as soon as reasonably practicable, within 24 hours from receiving the certificate revocation request at the latest.

Fina CA, Fina RA Network Officers and Fina Call Centre employees may suspend the certificate prior to its revocation. The suspension rules are listed in Section 4.9.13. of this CPSNQC document.

Immediately upon certificate revocation, Fina CA shall change certificate status, as well as issue and publish a new CRL. All revocation requests and documentation related to procedures carried out by Fina CA shall be archived.

4.9.6. Revocation checking requirement for relying parties

Before relying on a certificate, the Relying Party shall check the certificate status with the aim of determining whether it has been revoked or suspended, in accordance with procedures provided for in Section 4.5.2. of this CPSNQC document. If the Relying Party cannot obtain certificate status information at the given moment, they shall reject certificate usage until the moment they will be able to obtain status information.

4.9.7. CRL issuance frequency

CRL shall issue for Fina RDC 2015 and sign Fina RDC 2015, and CRL shall issue for Fina RDC-TDU 2015 and sign Fina RDC-TDU 2015. These CRLs are issued and published immediately upon revocation, suspension or reactivation of any certificate issued by the pertaining Fina CA.



CRL shall issue and publish immediately the pertaining Fina CA at least once within 24 hours from the moment of issuing the last current and still valid CRL.

4.9.8. Maximum latency for CRLs

Maximum latency for CRL from the moment of its issuance to the moment of its publication in regular circumstances shall never exceed two minutes.

4.9.9. On-line revocation/status checking availability

Fina CAs support on-line status check of issued certificates revocation via Fina OCSP 2015 service operating based on OCSP protocol.

Information on the certificate revocation status via Fina’s OCSP 2015 service is available in real time.

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

CRL is available primarily through HTTP Internet address on the server of the corresponding repository, and secondarily through LDAP Directory, as described in Section 4.10.1 of this CPSNQC document. Data on access points for retrieving CRL are contained in each issued certificate.

4.9.10. On-line revocation checking requirements

In order to download a CRL on-line, the Relying Parties shall have access to the Internet and use Internet browsers or applications which enable CRL download from Internet addresses, and to protocols referred to in Section 4.10.1. of this CPSNQC document.

4.9.11. Other forms of revocation advertisements available

Not supported.

4.9.12. Special requirements re key compromise

No requirement.

4.9.13. Circumstances for suspension

Fina CA shall suspend a certificate in the following cases:



• when a Subscriber, a Signatory or a Custodian, due to suspicion referred to in

Section 4.9.1. of the CPSNQC document requires certificate suspension until such suspicion is confirmed or removed (resulting in certificate revocation or reactivation, accordingly);

• temporarily until revocation that has been requested due to the reasons referred to in Section 4.9.1. of the CPSNQC document while Fina or RA Network run all necessary certificate revocation checks or until the revocation documentation is delivered to RA Network;

• default by Subscriber regarding the payment of services provided.

4.9.14. Who can request suspension

The Signatories shall be authorised to submit the corresponding personal certificates suspension requests.

The suspension request related to business certificates issued to natural persons, business certificates for IT equipment and TDU certificates may be submitted by the Signatory, or the Custodian, or the business entity authorised representative.

RA Network may file the certificate revocation request on its own behalf.

Business entity authorised representative can submit a revocation request regarding an associated person’s certificate.

An RA Network Officer can submit a certificate suspension request filed by the Subscriber, Signatory or Custodian, or they can submit a request on behalf of RA Network. A certificate revocation request submitted on behalf of RA Network shall be authorised by a direct head of the RA Network Officer who submitted the request.

Fina CA may request suspension of any issued certificate, subject to Fina PMA's approval.

Fina CA shall notify in writing the corresponding Signatory or the Custodian and, if applicable, the Subscriber of the performed certificate suspension. Signatories, Custodians and Subscribers who have listed their e-mail address in the certification application shall be notified by e-mail, whereas other Signatories, Custodians and Subscribers shall be notified by mail.

The Signatories shall be authorised to submit the corresponding personal certificates reactivation requests.

The reactivation request related to business certificates issued to natural persons, business certificates for IT equipment and TDU certificates shall be submitted by the Signatory, or the Custodian, and it shall additionally be signed by the business entity authorised representative.



4.9.15. Procedure for suspension request

4.9.15.1. Procedure for suspension request

A certificate suspension request shall be in form of the certificate revocation, suspension, reactivation or recovery request, which is available on Fina PKI repository’s website referred to in Section 2.2. of this CPSNQC document. Immediately upon occurrence of any or all reasons for suspension under Section 4.9.13. of this CPSNQC document, the certificate suspension request shall be filled in accurately and entirely, as well as signed and submitted as soon as possible to Fina PKI by one of the following methods:


A filled-in and personally signed certificate suspension request, with direct identification of the Applicant according to the procedure described in Section 3.4.6. of this CPSNQC document, shall be delivered to an RA Network Officer.


A filled-in and personally signed certificate suspension request, with direct identification of the Applicant according to the procedure described in Section 3.4.7 of this CPSNQC document, shall be delivered by mail or courier to RA Network.

• by calling the Fina Call Centre:

The Applicant shall state the following data for the purpose of specifying the certificate suspension request:

- certificate serial number; or - Signatory’s name and surname and serial number (if contained in the certificate

DN) or name of the application or FQDN server, business entity name in case of a business certificate suspension request;

The Applicant shall state the following data for the purpose of identification:

- the Applicant’s name and surname; - the Applicant’s OIB; - business entity name (in case of a business certificate revocation request); - the Applicant’s contact number or e-mail address.

A Call Centre employee shall check the received responses in order to identify the Applicant by comparing them with data from the RA database regarding the certificate for which suspension has been requested.

If the suspension request was received during Fina CA office hours, the Call Centre shall check the request data and forward the suspension request to Fina CA.

If the certificate suspension request received by phone was received outside Fina CA office hours, a Call Centre authorised person shall check the data and suspend the



certificate. Fina CA shall change the certificate status and publish a new CRL list containing certificate suspension information. The Call Centre authorised person shall notify the Signatory and the authorised representative, if applicable, of the performed suspension.

• by telefax:

A filled-in and personally signed certificate suspension request shall be submitted, and the Applicant shall be identified by telefax according to the procedure described in Section 3.4.9. of this CPSNQC document.


A filled-in certificate suspension request, which the Applicant has signed with an advanced electronic signature, shall be delivered and the Applicant shall be identified according to the procedure described in Section 3.4.10.

An RA Network Officer shall follow the following procedure when receiving personally-submitted certificate suspension requests:




• if the Applicant’s verification was not successful, the RA/LRA Officer shall reject the certificate suspension request;

• the RA Network Officer shall forward the request to Fina CA for suspension procedure.

When receiving a suspension request by mail or courier at RA Network address:




• if the Applicant’s verification was not successful, the RA Network Officer shall reject the certificate suspension request and notify the Applicant thereof;

• the RA Network Officer shall forward the suspension request to Fina CA for suspension procedure.



Fina CA procedure when receiving suspension requests by an RA Network Officer:

• based on a suspension request, an authorised person of Fina CA or the Central Fina RA shall suspend the certificate by changing its status and publishing a new CRL list containing the certificate suspension information;

• Fina CA shall notify the Signatory, Custodian or authorised representative, if applicable, of the suspension performed.

If Fina CA has received the certificate suspension request by e-mail sent directly by the Applicant or an External RA, Fina CA shall perform the following procedure:

• an authorised person of Fina CA or the Central Fina CA shall verify an advanced electronic signature contained in the suspension request;

• the authorised person of Fina CA or the Central Fina CA shall verify correctness and integrity of data contained in the suspension request;

• the authorised person of Fina CA or the Central Fina RA shall suspend the certificate and publish s new CRL list containing the certificate suspension information;

• Fina CA shall notify by e-mail the Signatory, Custodian or authorised representative, if applicable, of the suspension performed.

Following certificate suspension, the Subscriber, Signatory or Custodian can request certificate revocation or reactivation.

If a suspended certificate is to be revoked, the applicable procedure is described in Section 4.9.3. of this CPSNQC document.

4.9.15.2. Procedure for reactivation request

A certificate reactivation request shall be in form of the certificate revocation, suspension, reactivation or recovery request, which is available on Fina PKI repository’s website referred to in Section 2.2. of this CPSNQC document. The request shall be accurately and entirely filled it, signed and delivered to Fina PKI by one of the following methods:


A filled-in and personally signed certificate reactivation request, with direct identification of the Applicant according to the procedure described in Section 3.4.1. of this CPSNQC document, shall be delivered to an RA Network Officer.


A filled-in and personally signed certificate reactivation request, with direct identification of the Applicant according to the procedure described in Section 3.4.2. of this CPSNQC document, shall be delivered by mail or courier to RA Network.




A filled-in reactivation request, which the Applicant has signed with an advanced electronic signature, shall be delivered and the Applicant shall be identified according to the procedure described in Section 3.4.5.

An RA Network Officer shall follow the following procedure when receiving personally-submitted certificate reactivation requests:




• if the Applicant’s verification was not successful, the RA Network Officer shall reject the certificate reactivation request;

• the RA Network Officer shall forward the reactivation request to Fina CA for reactivation procedure.

When receiving a reactivation request by mail or courier at RA Network address:




• if the Applicant’s verification was not successful, the RA Network Officer shall reject the certificate reactivation request and notify the Applicant thereof;

• the RA Network Officer shall forward the reactivation request to Fina CA for reactivation procedure.

If Fina CA has received the certificate reactivation request by e-mail sent directly by the Applicant or an External RA, Fina CA shall perform the following procedure:

• an authorised person of Fina CA or the Central Fina CA shall verify an advanced electronic signature contained in the reactivation request;

• the authorised person of Fina CA or the Central Fina CA shall verify correctness and integrity of data contained in the reactivation request;

• the authorised person of Fina CA or the Central Fina RA shall reactivate the certificate and publish s new CRL list no longer containing the certificate suspension information;

• Fina CA shall notify by e-mail the Signatory, Custodian or authorised representative, if applicable, of the reactivation performed.



In case of an incomplete request or if any other below-mentioned reasons exist as to why the certificate cannot be reactivated, the RA Network Officer shall reject the reactivation request. Once the reasons as to why the certificate could not have been reactivated no longer exist, the Applicant can once again request certificate reactivation.

A reactivation request can be rejected for the following reasons:

• false data; • unduly signed or unduly sealed application or agreement; • previous inappropriate procedures and default of Subscriber’s obligations; • statutory ban.

Fina CA procedure when receiving reactivation requests:

• based on a reactivation request, an authorised person of Fina CA or the Central Fina RA shall reactivate the certificate by changing its status and publishing a new CRL list no longer containing the certificate suspension information;

• Fina CA shall notify the Signatory, Custodian or authorised representative, if applicable, of the suspension performed.

If Fina CA has received the certificate reactivation request by e-mail sent directly by the Applicant or an External RA, Fina CA shall perform the following procedure:

• an authorised person of Fina CA or the Central Fina CA shall verify an advanced electronic signature contained in the reactivation request;

• the authorised person of Fina CA or the Central Fina CA shall verify correctness and integrity of data contained in the reactivation request;

• the authorised person of Fina CA or the Central Fina RA shall reactivate the certificate and publish s new CRL list no longer containing the certificate suspension information;

• Fina CA shall notify by e-mail the Signatory, Custodian or authorised representative, if applicable, of the reactivation performed.

4.9.16. Limits on suspension period

Maximum suspension period shall be 60 days. After such period, Fina CA shall revoke the certificate and publish its CRL.



4.10. Certificate status services

4.10.1. Operational characteristics

Certificate status check services shall ensure information on certificate revocation status whose Period of validity has not expired. Certificate status check shall be carried out by the use of OCSP service or CRL.

Relying Parties are recommended to use Fina's OCSP service for certificate status check, and the status check through retrieval of a CRL may be used as an alternative check method in case of OCSP service unavailability.

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

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

CRL publication addresses are contained in the CRLDistributionPoints extension in each issued certificate and are entered in the following order:

1. consolidated CRL address on the web server; 2. consolidated CRL address in the public directory; 3. segmented CRL address in the public directory, including numerical designation of

the segment.

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

If the Relying Party's application supports operation with a segmented CRL, it may retrieve a certain segment of a segmented CRL by using another CDP located in the CRLDistributionPoints extension in each certificate issued.

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

1. the Relying Party’s application shall retrieve a consolidated CRL from the web server at the address published in the first CRL, in the CRLDistributionPoints extension, in each certificate issued.

2. if the Internet server is not available, the Relying Party’s application shall retrieve a consolidated CRL from the public directory at the address published in the first CRL, in the CRLDistributionPoints extension, in each certificate issued.

http://ocsp.fina.hr/



4.10.1.1. Retrieval addresses for CRL lists of Fina RDC 2015 certificates

The consolidated CRL list web server address for Fina RDC 2015 certificates is: http://rdc.fina.hr/RDC2015/FinaRDCCA2015.crl.

CRL list can be retrieved in the DER, PEM and text format on the following website: http://www.fina.hr/finadigicert .

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

ldap://rdc-ldap2.fina.hr/cn=Fina%20RDC%202015,o=Financijska%20agencija, c=HR?certificateRevocationList%3Bbinary

The segmented CRL list public directory address for Fina RDC 2015 certificates is: CN=CRL1, CN=Fina RDC 2015, O= Financijska agencija, C=HR

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

4.10.1.2. Retrieval addresses for CRL lists for Fina RDC-TDU 2015 certificates

The consolidated CRL list web server address for Fina RDC-TDU 2015 certificates is: http://rdc.fina.hr/RDC-TDU2015/FinaRDC-TDUCA2015.crl.

CRL list can be retrieved in the DER, PEM and text format on the following website: http://www.fina.hr/finadigicert .

The consolidated CRL list public directory address for Fina RDC-TDU 2015 certificates is:

ldap://rdc-tdu-ldap2.fina.hr/cn=Fina%20RDC-TDU%202015,o=Financijska%20agencija, c=HR?certificateRevocationList%3Bbinary

The segmented CRL list public directory address for Fina RDC-TDU 2015 certificates is: CN=CRL1, CN=Fina RDC 2015, O= Financijska agencija, C=HR

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

4.10.2. Service availability

CRLs issued and published by Fina CAs are available 24 hours a day, seven days a week. In the event of a system failure, circumstances beyond Fina's control or force majeure, the service shall be available as long as possible in accordance with best business practices.

4.10.3. Optional features

No stipulations.

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


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




4.11. End of subscription

If a Subscriber intends to terminate the Subscriber Agreement, they shall send a Subscriber Agreement termination request to the RA Network.

The Subscriber may terminate the Agreement in writing without stating any reasons.

Fina shall terminate the Agreement if:

• business entity, Signatory or Custodian fail to meet the requirements stipulated in the Policy [36] and the Certification Service Terms and Conditions, or

• business entity, Signatory or Custodian act contrary to the Subscriber Agreement.

Agreement termination shall also mean revocation of all certificates issued under the Subscriber Agreement.

Addresses of Fina RA Network locations can be found in the on-line part of the repository referred to in Section 2.2. of this CPSNQC document. Address of the Certification Service Provider is listed in Section 9.11. of this CPSNQC document.

Following the Agreement termination, Fina CA shall revoke all certificates to which the Agreement relates, and it shall notify the Subscriber of the Agreement termination.

4.12. Key escrow and recovery

Fina CA shall carry out Subscriber private key escrow only for NCP and LCP certificates of standard level of security, which are downloaded using the Fina CMS system and saved in the key software storage.

4.12.1. Key escrow and recovery policy and practices

Fina CMS system shall destroy the legible form of the User's private key so that it cannot be recovered, and it shall save the PKCS#12 file.

Private key escrow procedure shall be as follows:

• Fina CMS system shall generate Subscriber key pair and shall forward the public key to Fina CA for certification;

• having received the certificate, Fina CMS shall create a PKCS#12 file to be downloaded by the Subscriber;

• at the beginning of the PKCS#12 file download process, the Signatory, or the Custodian, shall use secret information to encrypt content of the PKCS#12 file so it becomes legible solely for the Signatory, or the Custodian;

• Fina CMS system shall destroy the legible form of the Subscriber private key so that it cannot be recovered, and it shall save the PKCS#12 file in the file system.



Only the Signatory, or the Custodian, could recover such a PKCS#12 file with the private key because a secret information is required for decryption, and only the Signatory, or the Custodian, is familiar with such secret information. The Signatory, or the Custodian, can download the encrypted PKCS#12 file only after a two-factor authentication in the Fina CMS system.

4.12.2. Session key encapsulation and recovery policy and practices

Not applicable.



5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

Fina as a Certification Service Provide which issues Non-Qualified and Qualified Certificates, as well as Time Stamps shall apply adequate physical protection measures to the certification system.

Protection measures for issuing Non-Qualified Certificates and Time Stamps are identical to the physical protection measures which are prescribed for Qualified Certificates issuance and play one of the main roles in building trust regarding issued Non-Qualified certificates and Time Stamps by Fina.

This Chapter includes a description of physical protection systems applied in the Fina PKI system. A more elaborate description of systems for physical protection of devices, equipment and data which are used in Fina PKI system is found in Fina's internal documents.

5.1. Physical controls

Fina, as a Certification Service Provider which issues Non-Qualified Certificates and Time Stamps, applies physical protection measures to the system in accordance with Fina's business policy, laws in force and international recommendations.

Fina shall apply physical protection measures to the system in order to limit access to hardware and software components of the system, such as servers, workstations, cryptographic modules, network devices and pertaining software in Fina CAs, archives and repository, as well as to limit access to the data of registered natural persons and business entities. Physical access to the aforementioned equipment is described under section 5.2.1. of this CPSNQC document.

5.1.1. Site location and construction

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

The purpose of Fina's secondary certification system, located on a separate remote site, shall be to take over the functions of the primary certification system in case of failure until its recovery and restoration of services.

Compared to the primary system, the secondary system shall meet equal or higher security requirements.



5.1.2. Physical access

Physical access to Fina CA system, Fina QTSA system, Fina RA system, repository and archive shall be protected pursuant to the laws in force and the internal rules, and every access shall be registered.

Physical access to data which are collected by RA Network is granted only to authorised personnel of Fina CA and Fina RA Network, i.e. authorised persons of the External RA, who must collect, store, use and delete personal data on natural persons and business entities pursuant to the adequate legislation on personal and business data protection.

5.1.3. Power and air conditioning

All devices and premises within Fina's certification system located at Fina PKI's protected premises shall have backup power supply ensured by a device for constant power supply in combination with diesel aggregate which enables continuous and reliable work of certification systems until their recovery and restoration of the primary power supply.

All premises with certification system equipment shall have air conditioning systems installed for maintaining the prescribed working environment.

5.1.4. Water exposures

Equipment for issuing Qualified certificates within Fina's system is located in premises which are secured against flood.

5.1.5. Fire prevention and protection

Fina's system for issuing Non-Qualified certificates shall be protected by an automatic fire protection system in line with adopted laws in force.

5.1.6. Media storage

Media with safety backup copies of Fina CAs, central Fina RA system, repository content backups, media with electronic archive and media with safety backup of software equipment from the certification system shall be safely stored on two remote protected sites in order to avoid damage, theft or unauthorised access.

5.1.7. Waste disposal

Documents and data in hard or soft copy form located in Fina PKI protected premises, which do not require archiving, shall be safely removed and destroyed.



Waste disposal from the Fina PKI protected premises shall be effected under the supervision of authorised employees in Fina PKI.

Documents and data in hard or soft copy form which do not require further archiving, shall be safely removed from the archive system and destroyed.

Methods for destroying private keys are described in Section 6.2.10. of this CPSNQC document.

5.1.8. Off-site backup

Backup copies by Fina CAs, central Fina RA system, repository content copies and archives in electronic form, software equipment backup copies and system log copies which are kept in hard copy form shall be stored on another remote protected site.

Backup copies stored on another protected remote site shall be stored with the equal or higher security level of physical protection, unlike their original documents.

5.2. Procedural controls 5.2.1. Trusted roles

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

Trusted roles shall be assigned to authorised persons of Fina's competent organisational sections.

5.2.2. Number of persons required per task

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

Access and work on Fina PKI protected premises shall be performed in the presence of at least two authorised persons having access permissions for the Fina PKI's protected premises.

5.2.3. Identification and authentication for each role

Identification of authorised persons and assignment of access rights for specific tasks in Fina PKI shall be effected through security procedures as well as through verification procedures.



5.2.4. Roles requiring separation of duties

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

• Security Official, Fina's central RA Official/LRA Official shall not be assigned the System supervision Official role;

• System Administrator shall not be assigned Security Official or System supervision Official roles.

5.3. Personnel controls

5.3.1. Qualifications, experience and clearance requirements

Requirements for adequate professional qualification for each trusted and user role shall be taken into account at the time of hiring personnel for tasks in Fina CA or Fina QTSA systems.

Before starting to work at Fina CA, the candidates shall have appropriate expertise regarding work with PKI technology, expertise in the procedures for protection of computer equipment and software used in Fina CA and Fina QTSA systems.

Fina CA personnel with trusted roles shall not be in any conflict of interest which may pose a threat to the operation of Fina CA or Fina QTSA systems.

5.3.2. Background check procedures

Before hiring candidates to work on Fina CA and Fina QTSA tasks, Fina shall conduct adequate candidate checks in order to assess their appropriateness in accordance with the needs regarding the tasks they would be performing.

5.3.3. Training requirements

Employees performing tasks within Fina PKI are provided training and education pursuant to their trusted or user roles.

5.3.4. Retraining frequency and requirements

The knowledge of Fina RA Network shall be regularly refreshed, at least once every two years.

Fina CA and Fina QTSA personnel shall continuously refresh their specialist knowledge and skills.



5.3.5. Job rotation frequency and sequence

Not applicable.

5.3.6. Sanctions for unauthorised actions

Fina PKI shall undertake appropriate disciplinary sanctions pursuant to Fina's internal documents towards the persons who are not acting in accordance with Fina's Certificate Policy [36], CPSNQC document and other internal rules and documents.

In case of unauthorised action or misconduct of a Fina PKI authorised person, the provisions of law in force and Fina's internal rules shall be applied.

Such person shall be banned from performing Fina PKI tasks.

5.3.7. Independent contractor requirements

Independent contractors requirements are described in Fina's internal documents.

5.3.8. Documentation supplied to personnel

Every employee shall have at their disposal documentation necessary for performing their tasks, which includes internal and external materials for education and work instructions and procedures for performing specific tasks in Fina PKI, pursuant to the assigned or privileged user role and pertaining authorisations.

5.4. Audit logging procedures

5.4.1. Types of events recorded

All important events in the trustworthy Fina PKI systems related to certification and Time Stamps issuance shall be recorded as revision records in audit logs. Revision records shall contain:

• registration of a natural person and business entity; • certificate Issuance; • preparation and issuing of SSCD devices for NCP+ certificates; • life cycles and key management; • revocation, suspension and reactivation of certificates; • other material Fina PKI elements.



Time-Stamping Service

• all events related to Fina QTSA 2015 certificates issuance and renewal; • all events related to the management of Fina QTSA 2015 signing keys life-cycles; • all errors related to accurate time source, including deviation from permitted limits in

relation to the accurate time source.

5.4.2. Frequency of processing log

Fina CA and Fina QTSA 2015 trustworthy systems' logs shall be monitored and reviewed periodically. Actions undertaken based on log system collection shall be documented.

5.4.3. Retention period for audit log

Trustworthy system logs with records referred to in Section 5.4.1. are retained at least for 10 years.

5.4.4. Protection of audit log

Trustworthy system logs in Fina CA and Fina QTSA 2015 systems shall be protected by mechanisms and procedures ensuring confidentiality and integrity of the logs and not allowing records modification, nor easy records deletion or destruction.

System logs protected in such a manner shall be available only at the request of authorised persons, especially for the purpose of providing evidence on certificates and Time Stamps in court proceedings.

5.4.5. Audit log backup procedures

New Fina PKI system logs are copied and their copies are stored on the location of the secondary certification system which is on a separate location from the certification system in current use. The protection level of the audit log copies shall be equal or higher than the one applied to the logs on the primary production site.

5.4.6. Audit collection system (internal vs. external)

All systems log collection system in Fina PKI is an internal system which collects audit logs by combining automatic and manual processes which are carried out on Fina PKI servers and which are initiated, i.e. monitored by Fina CA personnel with trusted roles.



5.4.7. Notification to event-causing subject

Fina will, if necessary, notify the subject responsible for record-keeping about the event.

5.4.8. Vulnerability assessment

Results of audit log analyses are used for system vulnerability assessment.

Audit log analysis and monitoring of the implementation of all prescribed procedures shall be carried out by the authorised persons in Fina PKI.

5.5. Records archival

5.5.1. Types of records archived

At least the following Fina PKI system records, which may come in soft and/or hard copy, depending on the type, are archived:

• information about natural persons and business entities from the registration procedure and pertaining documentation;

• certificates and information about their issuance procedures; • records of revoked certificates and information about revocation procedures,

suspensions and reactivation of certificates and pertaining documentation; • data and documentation related to the SSCD devices; • issued Time Stamps; • confidential systems' logs; • relevant records related to Fina PKI operation and maintenance; • other Fina PKI documents according to laws in force.

Each archived record shall contain data indicating time referring to it.

5.5.2. Retention period for archive

All archived data and documentation shall be kept for at least 10 years.

5.5.3. Protection of archive

Archived data and documentation shall be protected by 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 protection level must be ensured also for archiving the data and documentation which are collected in the external RAs.

Archived records protected in such a manner shall be available only at the request of authorised persons, especially for the purpose of providing evidence on an issued certificate and Time Stamp in court proceedings.

5.5.4. Archive backup procedures

Security backup copy of Fina PKI record archive shall be created in Fina PKI's protected premises and stored in a secure manner on a remote location separate from the primary production certification system.

5.5.5. Requirements for time-stamping of records

No stipulations.

5.5.6. Archive collection system (internal or external)

Archived records shall be collected in a manner that depends on the type of record.

Records to be archived shall be collected and archived internally.

The collection of records to be archived which are created in the external RAs shall be regulated by a contract.

5.5.7. Procedures to obtain and verify archive information

Only persons authorised to access archive data shall have access to the archived data. Archive data shall be verified by their integrity control.

5.6. Key changeover

New Fina CA signing key pair generation, or Fina TSU signing key pair for Fina QTSA 2015 shall be performed timely prior to their expiry.

Fina CA, or Fina TSU signing key pair shall be generated in a manner described in Section 6.1 of this CPSNQC document.

The new Fina CA certificate with a newly generated public key shall be signed by Fina Root CA private key.

Fina shall duly notify Fina PKI participants about the planned Fina CA key changeover, on the repository web-page of the Fina CA in which the change is performed (refer to Sections



2.2.1. and 2.2.2. of this CPSNQC document). New Fina CA certificate shall be available to Fina PKI participants via the public directory and web-pages of the pertaining repository referred to in Section 2.2. of this CPSNQC document.

New Fina CA certificate shall be delivered to signatories, custodians and relying parties in the same manner in which the existing Fina CA certificate is delivered, pursuant to Section 6.1.4. of this CPSNQC document.

TSU public key for Fina QTSA 2015 Time Stamp signature verification is placed in Fina QTSA1 2015 certificate which is published in LDAP directory server rdc-ldap2.fina.hr and on the web-pages http://www.fina.hr/finadigicert.

5.7. Compromise and disaster recovery

Fina PKI has plans for system maintenance and recovery after a disaster, which also include procedures in case of Fina CA private keys compromise, or TSU private key for Fina QTSA 2015 compromise and in case of hardware and software malfunction and errors on the critical components of Fina CA or Fina QTSA 2015 system.

Internal plans include procedures for system maintenance and recovery in case of violation of rules for Fina CA access, or Fina QTSA 2015 system access, natural disasters, fire, power supply and communication interruptions, water pipe bursts, data theft or compromise, etc.

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

5.7.1. Incident and compromise handling procedures

Fina PKI has plans for certificate system preservation and recovery following a disaster.

Internal plans include procedures for the preservation and recovery of the system in case of accidents, such as equipment malfunctioning, human mistakes, theft or equipment and data compromise, fire, natural disaster, terrorist act, etc.

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

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

Plans laid down in Section 5.7.1. also include data recovery and equipment modification case of Fina PKI computing and network resources, software or data damage.




5.7.3. Entity private key compromise procedures

In case of Fina CA private key compromise, Fina shall:

• inform Fina RA/LRA and External RAs; • stop certificate issuance by Fina CA; • revoke all certificates issued using that key; • notify each user and all business entities with whom it has concluded an agreement

on certification services provision or with whom it is in business relation, and publish on the repository web-page of the compromised Fina CA (refer to Sections 2.2.1. and 2.2.2. of this CPSNQC document) a notification for relying parties stating that the certificates and information on the revocation status of certificates issued by Fina CA whose private key is compromised or there is a reasonable doubt that it is compromised, shall no longer be considered valid;

• establish the causes for Fina CA private signing key compromise; • generate a new Fina CA signing key pair; • issue a new Fina CA certificate; • publish the serial number of the compromised Fina CA certificate in the CRL which

will be signed by the new Fina CA private signing key; • enable the delivery of a new Fina CA certificate to the signatories, custodians and

relying parties pursuant to Section 6.1.4. of this CPSNQC document; • start issuing certificates by signing them with the new Fina CA private key and ensure

that the CRLs are signed using the new Fina CA private key, or that Fina OCSP service signs the responses using the newly-issued pertaining OCSP certificate.

In case of Fina QTSA 2015 private signing key compromise, Fina shall:

• stop Time Stamping Service; • inform Fina RA/LRA and External RAs; • take steps necessary for the revocation of Fina QTSA 2015 certificate; • notify each user and all business entities with whom it has concluded an agreement

on Time Stamping Service and publish a notification on the Fina QTSA web-page (refer to Section 2.1.2. of the Time Stamping Service Policy [37]) for the relying parties stating that the certificate shall no longer be considered valid;

• establish the causes for Fina QTSA 2015 private signing key compromise; • generate a new Fina QTSA 2015 signing key pair; • take steps necessary for issuing a new Fina QTSA 2015 certificate; • re-initiate Time Stamps issuance by signing them with a new Fina QTSA 2015 signing

key.

In case the used cryptographic algorithms and parameters cease to provide the required security protection, Fina shall:

• notify users and all business entities with whom it has concluded an agreement on providing the services in question, and post a notification on the Fina CA repository web-page (refer to Sections 2.2.1. and 2.2.2. of this CPSNQC document), or on Fina



QTSA web-page (refer to Section 2.1.2. of the Qualified Time Stamping Service Policy [37]) about the cryptographic algorithms compromise for the relying parties;

• revoke all certificates to which this refers.

5.7.4. Business continuity capabilities after a disaster

See Section 5.7.1

5.8. CA or RA termination

In case of External RA operation termination, its operations may be taken over by Fina RA/LRA. More specific provisions concerning the External RA operation termination are determined by mutual contractual obligations.

In case of ceased operation of the Fina RA network, Fina can entrust another legal person with the execution of subscriber registration activities.

In case of ceased certification services provision for a certain Fina CA, i.e. Fina QTSA 2015 terminating its operation, Fina will:

• notify all subscribers and all business entities with whom it has concluded agreements on the provision of the services concerned or with whom it has a business relationship in connection with the provision of certification services provided by Fina CA, i.e. Fina QTSA 2015 and the ministry competent for economy, at least three months before the termination of certification services provision to Fina CA, i.e. Fina QTSA 2015;

• publish a notification regarding the possible termination of the operation of a certain Fina CA, i.e. Fina QTSA 2015, on the web pages of the repository of the Fina CA which is terminating its operation (see points 2.2.1. and 2.2.2. in this CPSNQC

document), i.e. on the web page of the Fina QTSA repository (see point 2.2.3 in this CPSNQC document), intended for the relying parties, at least three months before the termination of the certification services provision by Fina CA, i.e. Fina QTSA 2015;

• ensure that the certification services provision is provided by another service provider for those subscribers who have been issued unqualified certificates by Fina CA if a service provider for this service of the same quality as Fina CA exists, and agrees to provide the services.

• In the absence of another service provider who would continue providing the certification services, Fina CA will revoke all unqualified certificates issued and promptly notify thereof the ministry competent for economy;

• ensure that another stamping service provider continues providing services to subscribers with whom agreements have been concluded regarding stamping service provision if such a service provider exists, of the same quality as Fina QTSA 2015, and promptly notify thereof the ministry competent for economy;



• ensure or transfer to another reliable business entity the responsibility of maintaining

Fina QTSA 2015 certificate with the public key available to the Relying Parties within a reasonable time period;

• deliver the gathered data specified in point 5.5.1. of this CPSNQC document to another service provider who is taking over the obligations regarding certification services provision for Fina CA, i.e. Fina QTSA, which is terminating its operation, i.e. the ministry competent for economy in the absence of such alternative provider;

• in the absence of another service provider who would continue providing certification services, Fina CA will continue maintaining the gathered data specified in point 5.5.1 of this CPSNQC document within the period specified in point 5.5.2 of this CPSNQC document or it will conclude an agreement for the maintenance of such data with another business entity;

• revoke all authorisations to any subcontracted business subjects who participate on the behalf of Fina CA or Fina QTSA 2015 in any part of the certification services provision process;

• for the Fina CA who is terminating its operation, destroy any corresponding private signing keys and all copies thereof;

• for Fina QTSA 2015 conduct all steps necessary for revoking the Fina TSU certificate, and destroy any private TSU keys and copies thereof.



6. TECHNICAL SECURITY CONTROLS

Fina PKI technical security requirements and applicable protection measures shall be determined according to the service type provided by its individual parts.

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

6.1. Key pair generation and installation

6.1.1. Key pair generation

6.1.1.1. Generating Fina CA Key Pair

Fina CA key pair generation procedure shall be carried out through a formal Fina CA key pair generation ceremony which shall be attended by Fina PKI's authorised persons.

Fina CA key pair generation ceremony shall be attended by a qualified auditor as a witness that the ceremony of Fina CA key pair generation is in compliance with Fina's documents, CA/Browser Forum Baseline Requirements [32] and the measures of technical safety pursuant to the HRN ETSI/EN 319 411-2 standards [11].

The cryptographic algorithm used for key generation and the key length for Fina CA shall be chosen in accordance with the ETSI TS 119 312 standardisation document [14] in order for them to be adequate during the entire period of CA certificate validity.

Key pair for Fina CAs shall be generated, under at least dual control of authorised persons with trusted roles in Fina PKI, on HSM modules meeting the requirements referred to in Section 6.2.1 of this CPSNQC document.

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

Fina CA key pair generation ceremony shall be carried out following a key generation protocol documenting the steps performed during a ceremony.

Fina CA key pair generation ceremony procedure shall be video recorded.

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



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

6.1.1.2. RA Key Pair Generation

a) NCP+ certificates for authorised persons from the Fina RA network

The authorised persons in the Fina RA network use the Business authentication N2 certificate (NCP+). The process of key pair generation for this certificate type is described in Section 6.1.1.3. of this CPSNQC document, where the signatory referred to in the aforementioned Section is the Fina RA Network authorised person, and the user location is the location within the Fina RA Network.

b) Normalised Certificates for IT equipment of the Central Fina RA system

Key pairs for normalised certificates for IT equipment of the Central Fina RA system shall be generated by Fina CA authorised persons. Key pairs shall be generated on the equipment of the Central Fina RA system.

c) Normalised certificates for IT equipment of the External RAs

Key pairs of all normalised certificates for IT equipment of the external RAs may be generated by Fina CA authorised persons or External RA persons. If the keys are generated by Fina CA authorised persons, the keys shall be generated in Fina PKI protected premises.

If the keys are generated by External RA persons, the keys shall be generated on the External RA location, in a manner which ensures compliance with technical requirements of the standards prescribed in Section 6.2.1. of this CPSNQC document.

6.1.1.3. Key Pair Generation for NCP+ User Certificates

a) Personal and Business NCP+ certificates


• Personal authentication N2 certificate (NCP+); • Business authentication N2 certificate (NCP+); and • TDU authentication N2 certificate (NCP+).

Key pairs for NCP+ personal and business user certificates shall be generated on SSCD devices.

If Fina CA generates a user key pair for NCP+ certificates, the keys on the SSCD device are generated in the Fina PKI protected premises, under Fina CMS system surveillance and management.



If Fina CA generates a user key pair, the keys on the SSCD device are generated in the Fina PKI operative premises of the protected premises referred to in Section 5.1.1. of this CPSNQC document, under Fina CMS system surveillance and management.

Insofar as key pairs are generated by Fina LRA or Central Fina RA authorised person, the keys are generated on a SSCD device under remote Fina CA supervision.

If a key pair is generated by its signatory, the keys on the SSCD device shall be generated on the user location, upon receiving SSCD device into RA Network, with immediate signatory identification and after the receipt of activation data. The signatory shall generate his/her key pair in one of the following two ways:

• If the signatory is registered in Fina RA Network or in RA Network of an External RA which does not use its own CMS in the procedure, the signatory shall authenticate himself/herself on a remote Fina CMS system via the secure SSL/TLS communication, using the provided activation data and the pertaining SSCD. During that procedure, under the remote online surveillance and management by Fina CMS system, the signatory shall generate his/her key pair on the SSCD device.

• If the signatory is registered in RA Network of the External RA and if the signatory generates the key for a Business authentication N2 certificate (NCP+), the External RA may use its own CMS system upon Fina's prior permission. The signatory shall authenticate on a remote CMS system of the External RA via the secure SSL/TLS communication, using the provided activation data and the pertaining SSCD. In the procedure, under remote online surveillance and management by the CMS system of the External CA, the signatory shall generate his/her key pair on SSCD device.

The signatory shall authenticate on a remote Fina CMS system via the secure SSL/TLS communication, using the provided activation data and the corresponding SSCD. During that procedure, under the remote online surveillance and management by Fina CMS system, the signatory shall generate his/her key pair on the SSCD device.

b) Certificate for Signing the Trusted List (NCP+)

This procedure shall apply to Certificate for Trusted list signing (NCP+). Key pair generation for this type of certificate shall be performed by Fina CA authorised persons on SSCD device in Fina PKI protected premises under surveillance and management by the Fina CMS system.

c) Business NCP+ Certificates for IT Equipment, Level 3


• SSL Certificate Level 3 (NCP+); • Application Certificate Level 3 (NCP+).

Generation of key pairs for Business NCP+ certificates for IT equipment of level 3 shall be performed by the custodian in the HSM module on its remote location.



d) Business NCP+ Certificates for IT Equipment, Level 2

This procedure shall apply to Level 2 Application certificate (NCP+). Generation of key pairs for this type of certificate shall be performed by the custodian on SSCD device on a remote location.

6.1.1.4. Key Pair Generation for NCP Certificates

a) Personal and Business NCP certificates


• Personal soft certificate (NCP); • Business soft certificate (NCP);

Key pairs for user NCP personal and business certificates shall be generated by the Fina CMS system within the Fina PKI protected premises..

b) SSL Certificate Level 2 (NCP)

Key pairs for Level 2 SSL certificates (NCP) shall be generated by Fina CMS system within the Fina PKI protected premises.

c) Application Certificate Level 2 (NCP)

Key pairs for Application certificate (NCP) Level 2 shall be generated by Fina CMS system within the Fina PKI protected premises.

d) Application Certificate Level 1 (NCP)

Key pair generation for Application certificate (NCP) Level 1shall be performed by Fina CMS system within the Fina PKI protected premises.

If key generation for NCP certificates is performed by a signatory or a custodian, the key generation shall be performed in a safe environment on a user location, under complete and sole control and responsibility of the signatory or custodian, i.e. the legal person to which they belong. For each NCP certificate type, Fina CA shall accept the public key of the prescribed length and used algorithms referred to in certificate profiles in Chapter 7. of this CPSNQC document.

6.1.1.5. Key Pair Generation for LCP Certificates

This procedure shall apply to Business Soft Certificate (LCP). Key pairs for this type of certificates shall be generated by Fina CMS system within the Fina PKI protected premises.

6.1.1.6. TSU Key Pair Generation for QTSA

The procedure for generating TSU key pairs shall be performed through the TSU keys generation ceremony. The performed TSU keys generation procedure shall be recorded with the accompanied audit logs.



TSU key pair generation ceremony for Fina QTSA 2015 shall be attended by the authorised persons in Fina PKI. TSU key pair generation for Fina QTSA 2015 shall be initiated by Fina CA authorised persons under Fina PMA authorised persons supervision.

TSU key pair shall be generated securely in HSM module which meets the requirements set out in Section 6.2.1. of this CPSNQC document.

TSU key pair shall be generated in HSM module, under dual control by the authorised persons of the service provider, and in compliance with the provisions of the HRS ETSI/TS 102 023 [17] standardisation document.

6.1.1.7. Key Pair Generation for Administrative Certificates

Key pairs for the Administrative N2 Certificate (NCP+) shall be generated by Fina CA authorised persons. Keys shall be generated on SSCD device in Fina PKI protected premises, under the surveillance and management by Fina CMS system.

6.1.2. Private key delivery to subscriber

If Fina CA generates the private key associated with NCP+ certificate for Fina RA Network authorised persons, the private key on SSCD device is personally delivered to Fina RA Network authorised person upon immediate prior identification.

If the Fina RA Network authorised person generates his/her private key associated with NCP+ certificate on SSCD device, under Fina CA's remote surveillance, it is deemed that the authorised person already possesses his/her own private key.

Private keys of normalised certificates for IT equipment in Fina RA system are generated on Fina RA IT equipment and, therefore, it is deemed that the Fina RA system already possesses them.

Insofar as Fina CA generates private keys for the External RA, private keys are personally, upon direct identification, delivered to custodians in a protected way. If the External RA generates private keys, it is deemed that it already possesses them.

In case Fina CA or Central Fina RA generates a private key for a signatory or application within the SSCD device, then the SSCD device with private key shall be delivered by protected channel to the Fina RA Network, and is personally delivered to the identified Signatory or Custodian.

In case Fina LRA generates a private key for a Signatory, or Custodian, on a SSCD device, then the SSCD device with the private key is personally delivered to the identified Signatory or Custodian.

Fina CA generates a private key for signing the Trusted list within the SSCD device and the SSCD device with private key shall be delivered by protected channel to the registration office of the RA network, and is personally delivered to the identified Custodian.



If a Signatory or Custodian at their site under remote surveillance of Fina CA generates a private key on a SSCD device, it shall be deemed that the Signatory or Custodian already possesses it.

If a user private key of the subject for NCP and LCP certificates is generated by Fina CA, the user private key shall be delivered to the authenticated signatory or custodian via the protected channel in PKCS#12 format using Fina CMS system.

If a Signatory or Custodian at their site generates a private key, it shall be deemed that the Signatory or Custodian already possesses it.

6.1.3. Public key delivery to certificate issuer

Insofar as the public key is generated by the Central Fina RA, Fina LRA or Signatory/Custodian, the public key shall be delivered to Fina CA in a way ensuring the connection between the verified identity of the subject and the pertaining public key which is being delivered for certification. Delivery procedures use PKCS#10 format which is signed by the subject's private key.

Public key in PKCS#10 format shall be delivered electronically through Fina CMS system or other Fina CA web service for sending public keys and downloading certificates, which all use SSL/TLS communication channel following the successfully performed signatory/custodian authentication.

6.1.4. CA public key delivery to relying parties

Public key for verifying Fina CA signatures shall be delivered via reliable channel to the signatories, or custodians, in the Fina CA certificate. Fina CA certificate shall be available to relying parties also on the corresponding web-pages of the repository referred to in Section 2.2. of this CPSNQC document. Authenticity of Fina CA certificate published on the web-pages shall be ensured by delivering its hash through a reliable channel.

6.1.5. Key sizes

Key sizes of the certificates within the scope of this CPSNQC document shall be as follows:

• Subordinated Fina CAs (Fina RDC 2015 and Fina RDC-TDU 2015) shall use sha256WithRSA algorithm with a key length of 4096-bits;

• Fina QTSA 2015 shall use 2048-bit long RSA key pair; • Fina OCSP service shall use 2048-bit long RSA key pair; • RA network shall use 2048-bit long RSA key pair; • It equipment of the RA system shall use 2048-bit long RSA keys; • key pair for personal and business Non-Qualified certificates shall be 2048-bit long

RSA;



• key pair for SSL certificates shall be 2048-bit long RSA; • key pair for application certificates shall be 2048-bit long RSA; • key pair for certificates for Trusted list signature shall be 2048-bit long RSA; • key pair for administrative certificates shall be 2048-bit long RSA.

6.1.6. Public key parameters generation and quality checking

When generating public key parameters in HSM modules and SSCD devices, Fina CA uses parameters generated for RSA algorithm according to FIPS 186-3 [31] (or later) or ANSI X9.31 standards.

When generating public key parameters in SSCD device, parameters generated for RSA algorithm according to ANS X9.31 standard are used.

When generating public key parameters in software cryptographic modules (for certificates for servers or applications), the Custodian must use software cryptographic modules that generate RSA public key parameters in line with FIPS 186-3 [31] (or later) or ANSI X9.31 standards.

Parameter quality of the public keys, which are generated on Fina CA and Fina TSU public key location, shall be ensured by the manufacturer of the equipment in which the keys are generated using quality generators of random numbers, manufactured in accordance with FIPS 186-3 [31] (or later) or ANS X9.31 norms.

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

Fina CAs use private signing keys for signing issued certificates and the pertaining CRL list(X.509 v3 KeyUsage Extension: keyCertSign, cRLSign).

Authorised persons within the Fina RA Network use private keys for authentication to Fina RA system (X.509 v3 KeyUsage Extension: digitalSignature, keyEncipherment).

Fina RA system uses keys for authentication to Fina RA system, for signing and encryption (X.509 v3 KeyUsage Extension: digitalSignature, keyEncipherment).

Fina QTSA 2015 system uses TSU private signing keys for electronic signature of Time Stamps (X.509 v3 KeyUsage Extension: digitalSignature, nonRepudiation; extKeyUsage extension: timeStamping).

Non-Qualified keys of the signatories are intended for electronic signatures, authentication and encryption (X.509 v3 KeyUsage Extension: digitalSignature, keyEncipherment).

SSL certificate keys are intended for electronic signature, authentication and encryption (X.509 v3 KeyUsage Extension: digitalSignature, keyEncipherment).

Application certificate keys are intended for electronic signature, authentication and encryption (X.509 v3 KeyUsage Extension: digitalSignature, keyEncipherment).



Keys for signing the Trusted list are intended for electronic signature of the Trusted list (X.509 v3 KeyUsage Extension: digitalSignature; extKeyUsage extension: id-tsl-kp-tslSigning).

Administrative certificate keys are intended for electronic signature, authentication and encryption (X.509 v3 KeyUsage Extension: digitalSignature, keyEncipherment).

6.2. Private Key Protection and Cryptographic Module Engineering Controls

6.2.1. Cryptographic module standards and controls

Fina CA, Fina QTSA 2015 and Fina OCSP private keys shall be generated in the HSM module which complies with the requirements of FIPS 140-2 [30], level 3 or higher.

All user keys for high level security certificates must be generated in the user's HSM module:

• which complies with the requirements according to FIPS 140-1 [29] or FIPS 140-2 [30] level 3 or higher, or

• requirements with applied equally valuable security criteria.

All user keys for medium level security certificates must be generated in a SSCD device that complies with one of the following forms of protection measures for creating an advanced electronic signature:

• FIPS 140-1 [29] or FIPS 140-2 [30], level 2 or higher, or • CEN/ISSS SSCD-PP defined by document CWA 14169 [19], or • requirements with applied equally valuable security criteria.

Exceptionally, for NCP medium level security certificates for servers and applications/service, user keys may be generated in a software or hardware cryptographic module that complies with requirements according to FIPS 140-1 [29] or FIPS 140-2 [30] level 1 or requirements with applied equally valuable security criteria with use of additional physical safety and ICT security measures.

If the custodian is generating keys for NCP certificates of a standard level of security, all of the keys must be generated in a cryptographic module which:

• complies with the requirements of FIPS 140-1 [29] or FIPS 140-2 [30] level 1 or higher; or

• the requirements with applied equally valuable security criteria;

and with the application of physical safety and ICT security measures.

The Fina RA network's authorised persons shall have medium level security certificates and their private keys shall be generated in the SSCD device.



The private keys for IT equipment of the central Fina RA system shall be generated in cryptographic modules which are at least FIPS 140-1 [29], level 1.

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

Multi-person control is a security mechanism which demands several authorisations for the access to Fina CA and Fina TSU via private signing keys. The control of Fina CA and Fina TSU private signing keys shall be carried out through the dual control of authorised persons with trusted roles in Fina PKI.

6.2.3. Private key escrow

The escrow of Fina CA private keys, or Fina TSU private keys outside of FINA shall not be applied.

Fina CA shall carry out the escrow of private user keys only for NCP and LCP certificates with a standard security level in an encrypted PKCS#12 form. The recovery of such an escrowed PKCS#12 file with a private key shall be possible only for the signatory, i.e. the custodian, since the decryption of a private keys is carried out using secret information known only to the signatory, i.e. the custodian.

6.2.4. Private key backup

The backup of a Fina CA private key shall be carried out under at least a dual control of Fina CA authorised personnel. When it is outside of a cryptographic module, the Fina CA private key shall be exclusively in encrypted form. Backup copies of Fina CA private keys shall be kept at separated and adequately protected locations.

Backup of the private TSU key for Fina QTSA 2015 shall be carried out in the same manner as for the Fina CA key.

Fina CA shall never carry out security backup of user private keys generated on SSCD devices.

Fina CA shall carry out user private key escrow only for non-qualified certificates of standard level of security (NCP and LCP) in the manner described in Section 6.2.3 of this CPSNQC document.

If a user private key was not generated on an SSCD device, the signatory, i.e. custodian, can make a private key backup on media for data storage insofar as this is technically possible.

A user's private key backup should be stored and protected with the same or greater level of protection than the original, to prevent unauthorised use and possible misuse of the private key.



The business entity, signatory or custodian shall be responsible for the protection of a user's private key backups, and shall be liable in the event of their unauthorised use in the same way as for the original, as described in section 4.5.1. of this CPSNQC document.

6.2.5. Private key archival

Private keys shall not be archived.

6.2.6. Private key transfer into or from a cryptographic module

The transfer of a private key subordinated to Fina CA to or from a cryptographic module has been described in section 6.2.6. of the Certification Practice Statement Fina Root CA, CPSROOT [38].

Fina OCSP 2015 service and Fina QTSA 2015 private keys shall be transferred in the same manner as subordinate Fina CAs' private keys.

The transfer of the corresponding business certificate private key for IT equipment into another cryptographic module shall be permitted for certificates issued for servers or applications.

The transfer of a signatory's private key for personal and business soft certificates (NCP and LCP) defined in section 1.1.2. of this CPSNQC document into another private key storage shall be carried out exclusively by the signatory.

In all the above cases in which the transfer of private keys shall be permitted, the following must be secured:

• Private key shall be transferred to a cryptographic module with equal or higher security level compared to the cryptographic module from which it is transferred;

• private key shall be adequately encrypted in order to be protected when outside the cryptographic module;

• when encrypting a private key, rules regarding the recommended length and choice of characters for the PIN, i.e. the password, need to be complied with;

• when transferring the private key, its integrity and authenticity need to be ensured.

The cryptographic module can be realised as an HSM module or a software cryptographic module.

6.2.7. Private key storage on cryptographic module

Private keys of subordinated FINA CAs shall be protected by cryptographic modules and they may be used only if duly activated.



Private keys of Fina QTSA 2015 shall be protected by cryptographic modules and they may be used only if duly activated.

Fina OCSP 2015 service response signing private keys shall be protected by cryptographic modules and they may be used only if duly activated.

6.2.8. Method of activating private key

The initiation of the CA service for certificate creation and the activation of a private Fina CA key, i.e. private TSU key of Fina QTSA 2015, in a hardware cryptographic module shall be carried out under the dual control of authorised persons of Fina CA.

Once activated, the private key stays active indefinitely.

The private signing key of a Fina RA/LRA officer shall be activated only by a corresponding Fina RA/LRA officer using the PIN for the corresponding SSCD device. While the private key is active, the Fina RA/LRA officer shall monitor its use and the SSCD device.

The private key of the certificate issued for the server, application or the Trusted List signature shall be activated solely by the corresponding custodian using the corresponding activation data. While the private key is active, the custodian ensures its adequate use.

The private key of a personal or business certificate issued to a signatory shall be activated solely by the corresponding signatory using the appropriate activation data. While the private key is active, the signatory shall monitor its use.

Only the signatory, i.e. custodian, knows the data for the activation of the private key. The signatory, i.e. custodian, carries out private key activation in such a way that the secrecy of the activation data is secured. The period during which the private key stays active is unlimited.

6.2.9. Method of deactivating private key

The private key deactivation methods shall be used for the deactivation of a private key when its use is no longer needed, immediately after its use or after the end of all activities where there was a recurring need for private key use.

The deactivation of a private key subordinated to Fina CA, as well as the deactivation of private keys for Fina OCSP 2015 and Fina QTSA 2015 service response signing has been described in section 6.2.9. of the CPSROOT document [38].

Activated subscriber cryptographic modules must not be left without supervision. When the use of a private signing key is no longer needed, the signatory, i.e. custodian, must deactivate the private key.

If a user private key is situated in the HSM module, its deactivation shall be carried out by the custodian in a trusted manner prescribed by the module manufacturer. Depending on the



HSM module execution manner, the deactivation shall be carried out via a logical deactivation of the HSM module, physical removal or activation device detachment, or by removing or detaching the HSM module.

If the user private key is situated in the SSCD device, its deactivation shall be carried out by the signatory, i.e. custodian, by physically removing or detaching the SSCD device, i.e. via a trusted logical deactivation prescribed by the SSCD device manufacturer.

If the user private key is situated in a software cryptographic module, its deactivation shall be carried out by the signatory, i.e. custodian, via a trusted logical deactivation prescribed by the software cryptographic module manufacturer or by shutting down the computer on which the private key is situated.

The trusted logical deactivation of the HSM module, SSCD device and the software cryptographic module can also be carried out by an application or operation system using trusted methods of logical deactivation prescribed by the module, i.e. SSCD device, manufacturer.

6.2.10. Method of destroying private key

Fina CA private keys, i.e. TSU private keys Fina QTSA 2015, shall be destroyed when their use is no longer needed, i.e. at the end of their life cycle.

The process of destroying private Fina CA keys, i.e. a private TSU key for Fina QTSA 2015, shall be carried out as described in section 6.2.10. of the CPSROOT document [38]. There are no provisions regarding the mandatory destruction of private keys of central Fina RA system IT equipment certificates, IT equipment certificates of external contracted RAs, business certificates for IT equipment, and business and personal signatory certificates.

6.2.11. Cryptographic Module Rating

Cryptographic modules shall be rated in accordance with standards for cryptographic modules described in section 6.2.1. of this CPSNQC document.

6.3. Other aspects of key pair management

6.3.1. Public key archival

Fina CA public keys, public TSU key Fina QTSA 2015 and Subscriber public keys of all the entities to whom certificates were issued shall be archived with the aim of enabling electronic signatures and time stamp verification, especially for the purpose of providing evidence on certificates and time stamps in court, administrative and other proceedings.



Fina CA public keys and the public TSU key Fina QTSA 2015 shall be archived by archiving Fina CA i.e. Fina QTSA 2015 certificates issued for these public keys.

Fina CAs shall archive public keys of all entities by archiving the certificates issued for these public keys.

Public key archiving shall be performed for the time period stipulated in Section 5.5.2. of this CPSNQC document.

The archived keys backup shall be created and kept as set out in Section 5.5.4. of this CPSNQC document.

6.3.2. Certificate operational periods and key pair usage periods

The envisaged validity period of certificates and key pair usage per type of certificate is shown in Table 6.1.

Certificate Term

Fina Root CA certificate 20 years

Fina RDC 2015 i Fina RDC-TDU 2015 CA-certificates 10 years

Fina QTSA 2015 time-stamp certificate 10 years

OCSP service response signing certificate 12 months

Standard level security certificate Not exceeding 5 years

Medium level security certificate 2 years

High level security certificate 1 year Table 6.1 - Certificate usage periods

Private keys shall be valid from the start until the end of the validity of the corresponding certificate. Certificates and pertaining private key shall not be used after the termination of the validity period of the certificate.

Validity period of each issued certificate is defined by values set out in the basic field Validity. Section 7.1. of this CPSNQC document includes the data for the value of the Validity field for all types of certificates within the scope of this document.

Validity period of the certificate and the pertaining private key may be permanently or temporarily shortened during the validity period by revocation i.e. suspension of the certificate.



6.4. Activation data

PIN, password or other type of activation data shall be used for the protection of access to private keys in Fina PKI.

6.4.1. Activation data generation and installation

The generation and installation of activation data for the Fina Root CA private key and for private keys of subordinated Fina CAs, as well as the generation and installation of activation data for Fina QTSA 2015 and Fina OCSP 2015 private keys is described in Section 6.4.1. of the document CPSROOT [38].

Activation data for private keys for IT equipment of the central Fina RA shall be generated by authorised persons of Fina CA in the Fina PKI protected premises.

If Fina CA generates a private key for IT equipment of a sub-contracted External RA, the pertaining activation data shall be generated by authorised persons of Fina CA in the Fina PKI protected premises. If a private key for equipment is generated at the site of a sub-contracted External RA, the pertaining activation data shall be generated by the Custodian at the site of a sub-contracted External RA.

Activation data for private keys of LRA Officers and for Subscriber private keys located in SSCD devices shall be safely generated by authorised persons of Fina CA in the Fina PKI protected premises

Activation data for private keys for certificates for signing Trusted lists shall be generated by Fina CA.

Activation data for Subscriber private keys located in the HSM module shall be generated the Custodian at its site.

In cases when the Signatory or the Custodian download certificates in the form of a PKCS#12 file by using the Fina CMS system, the private key shall be encrypted with a password chosen by the Signatory i.e. the Custodian during the SSL/TLS protected session. When importing the PKCS#12 file in the software storage of the computer, the Signatory i.e. the Custodian shall create a password for activating the private key in software storage.

In cases when the Custodian downloads certificates by using other Fina CA web services for sending a public key and downloading certificates, the Custodian shall create a password for activating the private key in software storage.

6.4.2. Activation data protection

The protection of activation data related to the Fina Root CA private key, subordinated Fina CAs and activation data related to a private key for Fina OCSP 2015 service and activation data related to a private key for Fina QTSA 2015 is described in Section 6.4.2. of the document CPSROOT [38].



Activation data for Subscriber private keys located in SSCD devices shall be kept in encrypted form in Fina CMS database in the Fina PKI protected premises. Only Fina CA authorised persons shall have access to such data.

Activation data generated by Fina CA for Subscriber private keys shall be delivered to the Signatory, or the Custodian by a distribution channel separate from the supply channel of the SSCD device and/or private key. It is recommended that the Signatory, or the Custodian changes the activation data upon the first key activation.

If the activation data for the IT equipment of the External sub-contracted RA is generated by the Custodian at the site of the External sub-contracted RA, it will be responsible for the security and quality of the activation data.

If the Signatory or Custodian generates activation data, then the same shall be responsible for the security and quality of the activation data.

It is recommended that for the Subscriber private keys that the Subscriber imports in the software key storage the Signatory or Custodian creates activation data to protect the private key.

It is recommended not to record the activation data. If the activation data is nevertheless recorded, such data has to be stored safely and be available only to the pertaining Signatory or Custodian, and such data shall not be stored together with the pertaining cryptographic modules where the protected Subscriber private key is located.

6.4.3. Other aspects of activation data

If the activation data for non-qualified Subscriber certificates are generated by Fina CA, the activation data shall be sent from Fina CA or RA network by e-mail or registered post to the Signatory or Custodian.

If the private key activation data located on SSCD device are sent by e-mail, the activation data shall be encrypted. If the activation data for the private key located and protected in the PKCS#12 file are sent, then the activation data shall be sent in two separate distribution channels.

If the activation data should be transferred, then during the transfer period the activation data shall be protected from theft, loss, changes, compromising and unauthorised use. The location to which the activation data are being transferred shall have the same or higher level of security than the location from which the activation data are being transferred.



6.5. Computer security controls

6.5.1. Specific computer security technical requirements

Fina shall ensure that all Fina PKI system computer security requirements are in line with the standardization documents HRS ETSI/TS 102 023 [17] and HRN ETSI/EN 319 411-3 [12] and the HRN ETSI/EN 319 411-2 [11]standardization document in cases when the latter sets stricter requirements for computer security and with requirements contained in CA/Browser Forum Baseline Requirements document [34].

6.5.2. Computer security rating

Security measures relating to computer security shall be periodically tested in accordance with the standards referred to in Section 6.5.1. of this CPSNQC document.

6.6. Life cycle technical controls

By performing regular periodic system controls and security controls of certification system management, Fina PKI shall ensure the compliance of the technical management of the Fina CA system life cycle with the requirements set out in the HRN ETSI/EN 319 411-3 [12] standardisation document, i.e. the ETSI/EN 319 411-2 [11] standardisation document in case the latter sets stricter certification system. Fina QTSA systems shall be managed in accordance with the requirements set out in the HRS ETSI/TS 102 023 [17] standardisation document.

6.6.1. System development controls

The Fina PKI system configuration management plan shall contain a clear overview of the current situation, list of documents drawn up during the information system development, quality assurance measures, vulnerability assessment, software design, system test and control mechanism definitions.

6.6.2. Security management controls

Procedures and forms of protecting the Fina CA and Fina QTSA 2015 information system are aligned with the HRN ISO/IEC 27001 [27] standardisation document.

6.6.3. Life cycle security controls

Fina CA staff shall perform the check of all parts of the certification system with regard to security, reliability and quality of functioning, in accordance with the stipulated procedures,



thereby ensuring that the Fina CA and Fina QTSA 2015 systems operate properly and in accordance with the implemented system configuration.

The Fina CA and Fina QTSA 2015 system check shall be performed prior to the provision of services, following significant modifications in the certification system during the provision of services, and regularly at least once a year.

The longest time period between the two check procedures shall not be longer than one year.

6.7. Network security controls

Security of the Fina PKI system computer network shall be checked pursuant to Fina's internal documents.

6.8. Time-stamping Not applicable.



7. CERTIFICATE, CRL, AND OCSP PROFILES

This chapter contains a description of the certificate's profiles, certificate revocation lists (CRL) and OCSP service responses that Fina, as a Certification Service Provider, issues by Fina RDC 2015 and Fina RDC-TDU 2015 CA, in accordance with the scope of this CPSNQC document.

The profiles of normalized certificates issued by Fina RDC 2015 and Fina RDC-TDU 2015 CA are aligned with the HRN ETSI/EN 319 411-3 [12] standard in the part of the certificate policy for NCP or NCP, and with IETF RFC 5280 [24] recommendation.

The profile of lightweight certificates issued by Fina RDC 2015 CA is aligned with the HRN ETSI/EN 319 411-3 [12] standard in the part of the certificate policy for LCP, and with IETF RFC 5280 [24] recommendation.

The profiles of CRLs that are issued by subordinated Fina CAs are aligned with IETF RFC 5280 [24] recommendation.

The profiles of OCSP responses that are issued by Fina OCSP service are aligned with IETF RFC 6960 [25] recommendation.

7.1. Certificate profile

Subordinated FINA CAs shall issue certificates according to the profiles that are determined by Certificate Policy [36]. 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 was issued, its security level and the way of its private key protection.

7.1.1 Version number(s)

X.509 version 3 of certificates shall be used.

7.1.2 Certificate extensions

Common extensions of all the certificates issued by Fina CAs are listed in Table 7.1.

Extension Critical Attribute Value

AuthorityKeyIdentifier NO keyIdentifier 160-bit SHA-1 hash value (determined according to RFC 5280, Section 4.2.1.2 method (1))

SubjectKeyIdentifier NO keyIdentifier 160-bit SHA-1 hash value (determined according to RFC 5280, Section 4.2.1.2 method (1))

BasicConstraints NO cA=FALSE pathLenConstraint=None

Table 7.1 Common extensions of all the certificates issued by Fina CAs



Fina RDC 2015 Non-Qualified Certificates

Certificates issued by FINA RDC 2015 CA per Subscriber groups:

1. Fina 2015 RDC Personal Normalized Certificates; 2. Fina 2015 RDC Business Normalized and Lightweight (LCP) Certificates; 3. FINA 2015 RDC Business Certificates for IT equipment; 4. FINA 2015 RDC Administrative Certificates.

Certificates issued by FINA RDC 2015 CA have common extensions profile certificates defined in the Table 7.2.


CRLDistributionPoints NO DistributionPoint

[1]URI: http://rdc.fina.hr/RDC2015/FinaRDCCA2015.crl ldap://rdc-ldap2.fina.hr/CN=Fina RDC 2015, O=Financijska agencija, C=HR?certificateRevocationList;binary [2]DirName:/C=HR/O= Financijska agencija /CN=Fina RDC 2015/CN=CRLx

Authority Information Access NO

id-ad-ocsp http://ocsp.fina.hr

id-ad-caIssuers http://rdc.fina.hr/RDC2015/FinaRDCCA2015.cer

Table 7.2 Common extensions of all the certificates issued by Fina RDC 2015 CA

1. Fina RDC 2015 Personal Normalized Certificates

Personal normalized certificates are issued by Fina RDC 2015 CA. This group of two types of normalized certificates is intended for natural persons for personal use.

• Personal authentication N2 certificate (NCP+) – Personal authentication normalized certificate of medium security level is used for strong authentication, electronic signature and encryption, and has assigned OID: 1.3.124.1104.5.12.1.4.2. This certificate is issued by Fina RDC 2015 CA on SSCD in accordance with the HRN ETSI/EN 319 411-3 (NCP+) [12] standard. The certificate is valid for two years.

Certificate extensions that are specific for Personal authentication N2 certificate (NCP+) are defined in Table 7.3.


subjectAltName NO rfc822Name Optional. Contains the e-mail address of the Signatory in IETF RFC 822 standardized form.

KeyUsage YES

digitalSignature digitalSignature bit is on

keyEncipherment keyEncipherment bit asserted

dataEncipherment dataEncipherment bit asserted

extKeyUsage NO emailProtection OID: 1.3.6.1.5.5.7.3.4

clientAuth OID: 1.3.6.1.5.5.7.3.2

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


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




certificatePolicies NO policyIdentifier OID: 1.3.124.1104.5.12.1.4.2

cPSuri http://rdc.fina.hr/RDC2015/FinaRDC2015-CP5-1-hr.pdf http://rdc.fina.hr/RDC2015/FinaRDC2015-CP5-1-en.pdf

policyQualifierID CPS

Table 7.3 Certificate extensions that are specific for Personal authentication N2 certificate (NCP+)

• Personal soft certificate (NCP) - Personal authentication normalized certificate of standard security level issued in PKCS#12 format, and used for strong authentication, electronic signature and encryption with assigned OID: 1.3.124.1104.5.12.1.3.1. This certificate is issued by Fina RDC 2015 CA in accordance with the HRN ETSI/EN 319 411-3 (NCP) [12] standard. The certificate is valid for five years.

Certificate extensions that are specific for Personal soft certificate (NCP) are defined in Table 7.4.



Key Usage YES





clientAuth OID: 1.3.6.1.5.5.7.3.2

certificatePolicies NO

policyIdentifier OID: 1.3.124.1104.5.12.1.3.1



Table 7.4 Certificate extensions that are specific for Personal soft certificate (NCP)

2. Fina RDC 2015 Business Normalized and Lightweight (LCP) Certificates Business certificates are issued by Fina RDC 2015 CA. This group of types of certificates is intended for business use and these certificates shall be issued to the associated persons within the business entity.

• Business authentication N2 certificate (NCP+) – Business authentication normalized certificate of medium security level is used for strong authentication, electronic signature and encryption, and has assigned OID: 1.3.124.1104.5.12.2.4.2. This certificate is issued by Fina RDC 2015 CA in accordance with the HRN ETSI/EN 319 411-3 (NCP+) [12] standard. The certificate is valid for two years.

http://rdc.fina.hr/RDC2015/FinaRDC2015-CP5-1-hr.pdf

http://rdc.fina.hr/RDC2015/FinaRDC2015-CP5-1-en.pdf





Certificate extensions that are specific for Business authentication N2 certificate (NCP+) are defined in Table 7.5.



KeyUsage YES digitalSignature digitalSignature bit is on




clientAuth OID: 1.3.6.1.5.5.7.3.2

certificatePolicies NO policyIdentifier OID: 1.3.124.1104.5.12.2.4.2

certificatePolicies NO cPSuri http://rdc.fina.hr/RDC2015/FinaRDC2015-CP5-1-hr.pdf http://rdc.fina.hr/RDC2015/FinaRDC2015-CP5-1-en.pdf


Table 7.5 Certificate extensions that are specific for Business authentication N2 certificate (NCP+)

• Business soft certificate (NCP) – Business authentication normalized certificate of standard security level issued in PKCS#12 format, and used for strong authentication, electronic signature and encryption, and has assigned OID: 1.3.124.1104.5.12.2.3.1. This certificate is issued by Fina RDC 2015 CA in accordance with the HRN ETSI/EN 319 411-3 (NCP) [12] standard. The certificate is valid for five years.

Certificate extensions that are specific for Business soft certificate (NCP) are defined in Table 7.6.



Key Usage YES





clientAuth OID: 1.3.6.1.5.5.7.3.2





Table 7.6 Certificate extensions that are specific for Business soft certificate (NCP)







• Business soft certificate (LCP) – Business authentication lightweight certificate of

standard security level issued in PKCS#12 format, and used for strong authentication, electronic signature and encryption, and has assigned OID: 1.3.124.1104.5.12.2.5.1. This certificate is issued by Fina RDC 2015 CA in accordance with the HRN ETSI/EN 319 411-3 (LCP) [12] standard. The certificate is valid for five years.

Certificate extensions that are specific for Business soft certificate (LCP) are defined in Table 7.7



Key Usage YES





clientAuth OID: 1.3.6.1.5.5.7.3.2





Table 7.7 Certificate extensions that are specific for Business soft certificate (LCP)

3. Fina RDC 2015 Business Certificates for IT equipment

Business Certificates for IT equipment are issued by Fina RDC 2015 CA. These certificates may be issued as:

• certificates for servers; • certificates for applications; • certificates for Trust list signing; • certificates for time-stamping; • OCSP service response signing certificate.

The following describes the extensions for certificates for servers.

• SSL Certificate Level 2 (NCP) – Normalized certificate for medium level security servers with software key storage use. This type of certificate has assigned OID: 1.3.124.1104.5.12.3.3.2. The keys of this certificate shall be generated by the Custodian in the software cryptographic module at its remote site. This certificate is issued by Fina RDC 2015 CA in accordance with the HRN ETSI/EN 319 411-3 (NCP) [12] standard. The certificate is valid for two years.





Certificate extensions that are specific for SSL Certificate Level 2 (NCP) are shown in Table 7.8.


subjectAltName NO dNSName or iPAddress

Fully qualified domain name (FQDN) of the server or server's IP address, (at least one entry).



extKeyUsage NO serverAuth 1.3.6.1.5.5.7.3.1

clientAuth 1.3.6.1.5.5.7.3.2





Table 7.8 Certificate extensions that are specific for SSL Certificate Level 2 (NCP)

• SSL Certificate Level 3 (NCP+) – Normalized certificate for high level security servers with HSM module use. This type of certificate has assigned OID: 1.3.124.1104.5.12.3.4.3. The keys of this certificate shall be generated by the Custodian in the HSM module at its remote site. This certificate is issued by Fina RDC 2015 CA in accordance with the HRN ETSI/EN 319 411-3 (NCP+) [12] standard. The certificate is valid for one year.

Certificate extensions that are specific for SSL Certificate Level 3 (NCP+) are shown in Table 7.9.



Fully qualified domain name (FQDN) of the server or server's IP address, (at least one entry).



extKeyUsage NO serverAuth 1.3.6.1.5.5.7.3.1

clientAuth 1.3.6.1.5.5.7.3.2





Table 7.9 Certificate extensions that are specific for SSL Certificate Level 3 (NCP+)

The following describes the certificate extensions for certificates for applications.

• Application certificate (NCP) Level 1 – Normalized certificate with standard level security for applications, with software key storage use. This type of certificate has assigned OID: 1.3.124.1104.5.12.5.3.1. The keys of this certificate shall be generated







by Fina RDC 2015 CA and certificate is issued in PKCS#12 form. This certificate is issued by Fina RDC 2015 CA in accordance with the HRN ETSI/EN 319 411-3 (NCP) [12] standard. The certificate is valid for up to five years.

In addition to the software key storage on the computer disc, the Subscriber can keep the private key corresponding to the public key of this type of certificate on a cryptographic device (smart card or USB token) and protect it by PIN.

Certificate extensions that are specific for Level 1 application certificate (NCP) are shown in Table 7.10.



Optional. Contains the e-mail address of the subject in IETF RFC 822 standardized form.

KeyUsage YES





clientAuth OID: 1.3.6.1.5.5.7.3.2





Table 7.10 Certificate extensions that are specific for Level 1 application certificate (NCP)

• Application certificate (NCP) Level 2 – Normalized certificate with medium level security for applications, with software key storage use. This type of certificate has assigned OID: 1.3.124.1104.5.12.5.3.2. The keys of this certificate shall be generated by the Custodian in the software cryptographic module at its remote site. This certificate is issued by Fina RDC 2015 CA in accordance with the HRN ETSI/EN 319 411-3 (NCP) [12] standard. The certificate is valid for two years.

In addition to the software key storage on the computer disc, the Subscriber can keep the private key corresponding to the public key of this type of certificate on a cryptographic device (smart card or USB token) and protect it by PIN.





Certificate extensions that are specific for Application certificate (NCP) Level 2, are shown in Table 7.11.




KeyUsage YES





clientAuth OID: 1.3.6.1.5.5.7.3.2





Table 7.11 Certificate extensions that are specific for Level 2 application certificate (NCP)

• Application certificate (NCP+) Level 2 – Normalized certificate with medium level security for applications, with SSCD device use. This type of certificate has assigned OID: 1.3.124.1104.5.12.5.4.2. The keys of this certificate shall be generated by the Custodian on SSCD device. This certificate is issued in accordance with the HRN ETSI/EN 319 411-3 (NCP+) [12] standard. These certificates are issued by Fina RDC 2015 CA. The certificate is valid for two years.

Certificate profile extensions that are specific for Application certificate (NCP+) Level 2, are shown in Table 7.12.




KeyUsage YES





clientAuth OID: 1.3.6.1.5.5.7.3.2





Table 7.12 Certificate extensions that are specific for Level 2 application certificate (NCP+)







• Application certificate (NCP+) Level 3 – Normalized certificate with high level

security for applications, with HSM module use. This type of certificate has assigned OID: 1.3.124.1104.5.12.5.4.3. The keys of this certificate shall be generated by the Custodian in the HSM at its remote site. This certificate is issued in accordance with the HRN ETSI/EN 319 411-3 (NCP+) [12] standard. These certificates are issued by Fina RDC 2015 CA. The certificate is valid for one year.

Certificate profile extensions that are specific for Application certificate (NCP+) Level 3, are shown in Table 7.13.




KeyUsage YES





clientAuth OID: 1.3.6.1.5.5.7.3.2





Table 7.13 Certificate extensions that are specific for Level 3 application certificate (NCP+)

• Trusted list signing certificate (NCP+) – Normalized certificate with medium level security for Trusted list signing, with SSCD device use. This type of certificate has assigned OID: 1.3.124.1104.5.12.8.4.2. The keys shall be generated by CA on SSCD device. This certificate is issued in accordance with the HRN ETSI/EN 319 411-3 (NCP+) [12] standard. These certificates are issued by Fina RDC 2015 CA. The certificate is valid for up to two years.

Certificate extensions that are specific for Trusted list certificate (NCP+) are shown in Table 7.14.



extKeyUsage NO id-tsl-kp-tslSigning OID: 0.4.0.2231.3.0





Table 7.14 Certificate extensions that are specific for Trusted list signing certificate (NCP+)







• Time stamp certificate (NCP+) – Normalized certificate with high level security for

qualified time stamps creation, with HSM module use. This type of certificate has assigned OID: 1.3.124.1104.5.12.52.4.3. The keys of this certificate shall be generated in HSM under the supervision of authorized persons of the qualified Time-Stamping Authority. This certificate is issued by Fina RDC 2015 CA in accordance with the HRN ETSI/EN 319 411-3 (NCP+) [12] standard. The certificate is valid for 10 years.

Certificate extensions that are specific for Time stamp certificate (NCP+) are shown in Table 7.15.



nonRepudiation nonRepudiation bit is on

extKeyUsage YES timeStamping OID: 1.3.6.1.5.5.7.3.8





Table 7.15 Certificate extensions that are specific for Time stamp certificate (NCP+)

• OCSP service response signing certificate (NCP+) – Normalized certificate for high level security OCSP service response signing with HSM module use. This type of certificate has assigned OID: 1.3.124.1104.5.12.9.4.3. The keys of this certificate shall be generated in HSM under the supervision of authorized persons of the Fina PKI. This certificate is issued by Fina RDC 2015 CA in accordance with the HRN ETSI/EN 319 411-3 (NCP+) standard and in accordance with the recommendation RFC 6960 [25]. The certificate is valid for twelve months.

Certificate extensions that are specific for OCSP service response signing certificate (NCP+) are shown in Table 7.16.




extKeyUsage NO OCSPSigning OID: 1.3.6.1.5.5.7.3.9

ocsp-nocheck NO OID: 1.3.6.1.5.5.7.48.1.5, value NULL


policyIdentifier High security level OID: 1.3.124.1104.5.12.9.4.3



Table 7.16 Certificate extensions that are specific for OCSP service response signing certificate (NCP+)







4. FINA RDC Administrative Certificates

Administrative Certificates shall be issued by FINA RDC 2015 CA. This group of certificates is intended for use within Fina certification system. These certificates shall be issued to Fina's authorised employees on SSCD devices.

SSCD device contains the following type certificate.

• Administrative N2 certificate (NCP+) – Administrative normalized medium security level certificate has assigned OID: 1.3.124.1104.5.12.6.4.2. This certificate is issued by Fina RDC 2015 CA in accordance with the HRN ETSI/EN 319 411-3 (NCP+) [12] standard. The certificate is valid for two years.

Certificate extensions that are specific for Administrative normalized certificate (NCP+) are shown in Table 7.17.


subjectAltName NO rfc822Name Optional. Contains the e-mail address of the Signatory in IETF RFC 822 standardized form..

Key Usage YES





clientAuth OID: 1.3.6.1.5.5.7.3.2



cPSuri

http://rdc.fina.hr/RDC2015/FinaRDC2015-CP5-1-hr.pdf http://rdc.fina.hr/RDC2015/FinaRDC2015-CP5-1-en.pdf


Table 7.17 Certificate extensions that are specific for Administrative N2 certificate (NCP+)

Fina RDC-TDU 2015 non-qualified certificates

Certificates issued by FINA RDC 2015 CA per Subscriber groups:

1. Fina RDC-TDU 2015 Certificates for end-entities; 2. Fina RDC-TDU 2015 Certificates for IT equipment.







Certificates issued by FINA RDC-TDU 2015 CA have common profile certificate extensions defined in the Table 7.18.


CRLDistributionPoints NO DistributionPoint

[1]URI: http://rdc.fina.hr/RDC-TDU2015/FinaRDC-TDUCA2015.crl URI: ldap://rdc-tdu-ldap2.fina.hr/CN=Fina RDC-TDU 2015, O=Financijska agencija, C=HR?certificateRevocationList;binary [2] DirName:/C=HR/O=Financijska agencija/CN=Fina RDC-TDU 2015/CN=CRLx

Authority Information Access NO

id-ad-ocsp http://ocsp.fina.hr

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

Table 7.18 Common extensions of all the certificates issued by FINA RDC-TDU 2015 CA

1. Fina RDC-TDU 2015 Certificates for end-entities

Certificates to state officials and state administration authorities' employees shall be issued by Fina RDC-TDU 2015.

• TDU authentication N2 certificate (NCP+) – Authentication normalized certificate of medium security level for state officials and employees is used for strong authentication, electronic signature and encryption, and has assigned OID: 1.3.124.1104.5.22.2.4.2. This certificate is issued by Fina RDC-TDU 2015 CA on SSCD in accordance with the HRN ETSI/EN 319 411-3 (NCP+) [12] standard. The certificate is valid for two years.

Certificate extensions that are specific for TDU authentication N2 certificate (NCP+) are shown in Table 7.19.



KeyUsage YES





clientAuth OID: 1.3.6.1.5.5.7.3.2



cPSuri

http://rdc.fina.hr/RDC-TDU2015/FinaRDC-TDU2015-CP5-1-hr.pdf http://rdc.fina.hr/RDC-TDU2015/FinaRDC-TDU2015-CP5-1-en.pdf


Table 7.19 Certificate extensions that are specific for TDU authentication N2 certificate (NCP+)




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

http://rdc.fina.hr/RDC-TDU2015/FinaRDC-TDU2015-CP5-1-hr.pdf


http://rdc.fina.hr/RDC-TDU2015/FinaRDC-TDU2015-CP5-1-en.pdf




2. Fina RDC-TDU 2015 Certificates for IT equipment

The IT equipment certificate group consists of OCSP service response signing certificate (NCP+).

• OCSP service response signing certificate (NCP+) – Normalized certificate for high level security OCSP service response signing with HSM module use. This type of certificate has assigned OID: 1.3.124.1104.5.22.9.4.3. The keys of this certificate shall be generated in HSM under the supervision of authorized persons of the OCSP service response provider. This certificate is issued by Fina RDC-TDU 2015 CA in accordance with the IETF RFC 6960 X.509 [25] standard. The certificate is valid for twelve months.

Certificate extensions that are specific for OCSP service response signing certificate (NCP+) are shown in Table 7.20.




extKeyUsage NO OCSPSigning OID: 1.3.6.1.5.5.7.3.9

ocsp-nocheck NO OID: 1.3.6.1.5.5.7.48.1.5, value NULL


policyIdentifier High security level OID: 1.3.124.1104.5.22.9.4.3

cPSuri

http://rdc.fina.hr/RDC-TDU2015/FinaRDC-TDU2015-CP5-1-hr.pdf http://rdc.fina.hr/RDC-TDU2015/FinaRDC-TDU2015-CP5-1-en.pdf


Table 7.20 Certificate extensions that are specific for OCSP service response signing certificate (NCP+)

7.1.3 Algorithm object identifiers

Algorithms and corresponding OID identifiers for all certificates issued in Fina PKI hierarchy based on Fina Root CA are shown in Table 7.21.

Algorithm OID

sha256WithRSAEncryption 1.2.840.113549.1.1.11

rsaEncryption 1.2.840.113549.1.1.1

Table 7.21. Algorithms and corresponding OID identifiers

7.1.4 Name forms

Name forms for subordinated Fina CAs are described in Section 1.3.2. of this CPSNQC document.







Name forms for certificates issued by subordinate Fina CAs are described in Sections 3.1.1. i 3.1.4. of this CPSNQC document.

7.1.5 Name constraints

Not applicable.

7.1.6 Certificate policy object identifier

Certificate Policies certificate extension of certificates issued in Fina PKI hierarchy based on Fina Root CA contains corresponding certificate policy OID specified in Table 1.1 in Section 1.1.2. of this CPSNQC document.

7.1.7 Usage of Policy Constraints extension

Not applicable.

7.1.8 Policy qualifiers syntax and semantics

Policy qualifiers in Certificate Policies certificate extension are two pointers in the form of a URI that contain web address to this Certificate Policy [36] document written in Croatian and English.

7.1.9 Processing semantics for the critical Certificate Policies extension

Not applicable.

7.2. CRL profile

CRL profile of CRLs issued by subordinated Fine CA's is in accordance with the IETF RFC 5280 recommendations [24].


X.509 version of 2 shall be used.

7.2.2 CRL and CRL entry extensions

CRL extensions used in the CRL lists and extensions used in entries of CRLs that are issued by Fina CAs are defined in Table 7.25.

Extensions Critical Value

crlExtensions

cRLNumber NO Monotonically increasing sequence number for CRL in the form of 20 bits number.

AuthorityKeyIdentifier NO 160 bits SHA-1 hash



Extensions Critical Value

crlExtensions

reasonCode NO Reason for the certificate revocation

Table 7.25 CRL and CRL entry extensions of CRLs that are issued by Fina CAs

7.3. OCSP profile

OCSP profile of OCSP responses issued by Fina OCSP services is in accordance with the IETF RFC 6960 recommendation [25].


Used version: 1 (0x0).

7.3.2 OCSP extensions

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



8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

The inspection of Fina PKI operation shall be regulated by the Electronic Signature Act [1], [2] and [3], and it shall be performed by the ministry of economy.

The Certification Service Provider operation in the field of collection, use and protection of the Signatory's personal data may be inspected by government and other bodies determined by law and other rules and regulations governing personal data protection.

Internal control of the implementation of stipulated rules and procedures regarding the operation of Fina PKI and implementation of the internal process for approving the operation of Fina CA and Fina QTSA 2015 in accordance with the rules defined in the Certificate Policy [36] and procedures set out in the CPSNQC document shall be carried out by internal assessors from the Office for e-Business policy management.

Compliance control of issuing non-qualified certificates issued by Fina CAs shall be carried out as set out in the HRN ETSI/EN 319 411-3 [12] standardisation document and in accordance with the quality level described for individual types of non-qualified certificates in this CPSNQC document.

Time-stamping compliance control shall be carried out as set out in the HRS ETSI/TS 102 023 [17] standardisation document.

Records of performed compliance controls performed may be available on request to external assessors during their Fina PKI system compliance control. The approval for providing the records of performed compliance controls to external assessors shall be given by Fina PMA.

The following sections of this Chapter shall regulate the carrying out of internal compliance control.

8.1. Frequency or circumstances of assessment

The Fina PKI operation compliance control shall be performed at least once a year. The compliance control shall be performed also before the start of the operation of a new Fina CA or Fina QTSA 2015 and after significant changes in the Fina PKI system operation, that is, after a disaster or a suspected system compromise.

8.2. Identity/qualifications of assessor

Internal assessors shall:

• be acquainted with and understand the provisions of HRN ETSI/EN 319 411-3 [12] and as well as the provisions of the standardisation documents HRS ETSI/TS 102 023 [17] i CWA 14167-1 [18];

• have up-to-date knowledge and skills in the fields of PKI and information security; • be acquainted with laws governing certification service provision.



8.3. Assessor's relationship to assessed entity

Internal compliance assessors shall be sufficiently organisationally and hierarchically separated from Fina CA in order to be able to perform an independent/neutral compliance control.

8.4. Topics covered by assessment

Internal assessors shall check whether Fina CA and Fina QTSA 2015 are acting in accordance with the Certificate Policy [36] and this CPSNQC document.

Certificate issuance system compliance control shall be carried out with regard to security, reliability and operation quality.

System documentation control shall encompass the control of document compliance with the requirements of legislation concerning electronic signature and the compliance with the HRN ETSI/EN 319 411-3 [12] standard.

System implementation control shall include the control of system compliance with the legal regulations on electronic signature, Certificate Policy [36], this CPNQC document and the HRN ETSI/EN 319 411-3 [12] standard.

Compliance control for time-stamping service shall be performed by documentation compliance control and system implementation control.

System documentation control of the time-stamping system shall encompass the control of document compliance with the requirements of legislation concerning electronic signature and the compliance with the HRS ETSI/TS 102 023 [17] standardization document.

Time-stamping system implementation control shall include the control of system compliance with the legal regulations on electronic signature, Qualified Time-Stamping Service Policy [37], this CPNQC document and the HRS ETSI/TS 102 023 [17] standardisation document.

8.5. Actions taken as a result of deficiency Should any non-compliance be identified in the Fina CA or Fina QTSA 2015 operation, the internal assessor shall prepare a report and submit it to Fina PMA, who shall, based on such report, develop a plan of actions, measures and procedures to be implemented by Fina CA or Fina QTSA 2015 in order to rectify the non-compliance identified in assessor's report within the set time period.

If significant non-compliance of Fina CA's operation is determined with regard to the requirements stipulated by this CPSNQC document, Fina PMA shall submit an application for termination of certificate issuance with those CP OIDs falling within the scope of this CPSNQC document or it shall file a request that Fina CA takes steps in order to rectify the non-compliance in a reasonable period. In case of certificate issuance termination, Fina PMA shall approve the continuation of certificate issuance after the assessor establishes that Fina CA achieved stipulated compliance.



During certification issuance termination due to the identified significant non-compliance, Fina CA may issue only those certificates which are indicated as certificates for internal and testing purposes and it shall ensure that those certificates are not available to any other Subscriber.

Fina CA, Fina QTSA and Fina RA/LRA shall keep internal logs with the list of time periods when they were not operating in accordance with the CPSNQC document, with stated reasons for such non-compliance.

8.6. Communication of results

Fina PMA, as the competent body, shall submit the compliance control report, as well as the plan of actions, measures and procedures to be undertaken in case of identification of non-compliance, to all responsible persons within Fina PKI system in charge of operation of system sections under compliance control.

The compliance control report prepared by an internal or external independent assessor shall be made available to Subscribers and Relying Parties as a proof of compliance.

In case the compliance control result affects other Fina PKI participants, Fina PMA shall post the compliance control summary relevant to subscribers and other Fina PKI participants on the repository referred to in Section 2.2. of the CPSNQC document.

All internal compliance control documents shall be available on request to external assessors performing the Fina PKI system compliance control.



9. OTHER BUSINESS AND LEGAL MATTERS

9.1. Fees

Fina and the RA Network shall inform the subscribers and relying parties about the price and collection method for services charged by Fina as the certification service provider. Informing the subscribers about the price and collection method shall be performed by RA/LRA officers in the RA Network, and by persons in Fina in charge of promotion and sale of products and services. Informing about the price and collection method shall also be performed by posting the price list and other relevant information on the web pages of Fina RDC 2015 and Fina RDC-TDU 2015 repository referred to in Section 2.2. of the CPSNQC document.

Unless otherwise determined by a separate agreement, the services shall be charged according to the price lists posted on the aforementioned repository pages.

9.1.1. Certificate issuance or renewal fees

According to the posted price list or pursuant to a separate agreement, Fina shall charge a service fee for issuing and renewing Fina RDC 2015 and Fina RDC-TDU 2015 non-qualified certificates.

9.1.2. Certificate access fees

Fina shall not charge certificate access fees.

9.1.3. Revocation or status information access fees

According to the posted price list or pursuant to a separate agreement, Fina shall charge a service fee for certificate revocation, and shall not charge a service fee for certificate suspension and reactivation.

Fina shall not charge a service fee for providing certificate status information.

9.1.4. Fees for other services

According to the posted price list or pursuant to a separate agreement, Fina or External sub-contracted RA shall charge a fee for the following services and products related to issuing normalized certificates:

• business entity and natural person registration service; • certificate data change; • smart card reader;



• direct identification of the Signatory or Custodian and delivery of certificate on a

SSCD device at the subscriber site; • rental and maintenance of electronic signature or encryption equipment.

Pursuant to the concluded agreement on the provision of time-stamping services, Fina shall charge for the provision of time-stamping services. Unless otherwise provided in a separate agreement, services shall be charged in accordance with Fina QTSA price list.

Fina shall not charge a fee for access to Certificate Policy [36], Time-Stamping Service Policy [37] and other documentation publicly posted on the internet section of the repository referred to in Section 2.2. of the CPSNQC document.

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 Certification Services Provider, shall have funds ensuring an unhindered certification service provision within the scope of this CPSNQC document regardless of the number of Subscribers and during the whole period of the provision of certification services.

9.2.1. Insurance coverage

Fina, as a Certification Services Provider, shall insure itself against damage liability risks for risks occurring during non-qualified certificate issuing and time-stamping services provision.

Fina shall additionally insure its assets by an insurance policy covering fire, adverse weather conditions, flood, explosions and similar risks, as well as a machinery breakdown insurance policy covering a possible loss which may occur as a result of failure of or damage to installations and/or electrical equipment, and glass breakage.

Fina may request from the External sub-contracted RA to insure itself from the damages that may arise from providing services contracted with External RA, in accordance with the terms and conditions of this certificate Policy and to appropriate amounts..

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 information in relation to certification service establishment and provision, regardless of their form, exchanged by the participants through any means of communication and labelled as confidential, or as being of a specific type or having a specific level of secrecy, by the participants, or which are confidential by their nature, for an unauthorised disclosure thereof might cause damage to the participant.

Confidential information shall also include all information relating to the manner and means by which Fina CA manages certificates and all information relating to the manner and means by which Fina QTSA 2015 issues time-stamps.

All Subscriber private keys generated by Fina CA and Fina LRA shall also be confidential. Pursuant to Sections 6.2.3. and 6.2.4., Fina CA shall store only the private keys generated for pertaining NCP and LCP certificates of a standard level of security. Private keys that Fina CA does not hold in escrow shall be delivered to the Subscriber, and at the latest upon delivery to the Subscriber, their possible copies shall be safely destroyed by Fina CA at its site.

9.3.2. Information not within the scope of confidential information

Confidential business information shall include all information in relation to certification service establishment and provision, regardless of their form, exchanged by the participants through any means of communication and not labelled as confidential, or as being of a specific type or having a specific level of secrecy, by the participants, or which are not confidential by their nature and an unauthorised disclosure thereof may not cause damage to the participant.

Business information integrated in the certificate contents displayed in public records and/or registers shall not be deemed confidential business information.

Business information integrated in the certificate contents displayed deemed as confidential business information shall include:

• abbreviated name of the business entity, or full name if the business entity does not have an abbreviated name;

• OIB of business entity; • registration number of Business entity assigned by the Croatian Bureau of Statistics; • name of the sub-organisational unit (for Fina RDC-TDU 2015 certificates); • Business entity registered office location; • Business entity country of registration.



The following business information displayed in public records and/or registers to be properly kept shall not be deemed confidential business information:

• lists of authorised representatives and their model of representation; • full name of the business entity; • main activity; • street and house number of the business entity's registered office address.

9.3.3. Responsibility to protect confidential information

Each Fina PKI participant shall protect confidential business information referred to in Section 9.3.1. of the CPSNQC document, that it has somehow become aware of, in accordance with laws regulating the data protection according to data type and information secrecy type and level. Otherwise, it shall be held liable for the damage occurred.

9.4. Privacy of personal information

Fina shall apply the provisions of Personal Data Protection Act [9] and other regulations, in particular those governing the personal data protection and data secrecy in the Republic of Croatia.

9.4.1. Privacy plan

Fina shall plan and implement stipulated technical, staff and organisational measures for the personal data protection against accidental or intentional misuse, destruction, loss, unauthorised modification or unauthorised access.

9.4.2. Information treated as private

During and after Subscriber registration procedure, Fina or External sub-contracted RA shall be authorised to collect and shall collect personal data required for valid Subscriber identification and other data required for valid certification service provision. Personal data collected by Fina or External sub-contracted RA and which are not integrated in the certificate contents, which are not displayed in public records and/or registers shall be deemed confidential personal data duly protected by Fina.

Personal data collected during the registration of a participant, custodian or other authorised representative, or after such registration, which are deemed as confidential, and which are properly protected by Fina, shall include:

• Citizen's Registration Number (MBG); • date of birth; • street and house number of the residence address; • nationality;



• information regarding the identification document of the person concerned: • phone, mobile and fax numbers; • postal address.

9.4.3. Information not deemed private

Personal data collected by Fina or External sub-contracted RA during and after the Subscriber registration procedure and which are integrated in the certificate contents displayed in public records and/or registers shall not be deemed confidential personal data due to their availability to all Fina PKI participants.

Personal data collected during the registration of a subscriber, or after such registration, which are not deemed as confidential due to their availability to all Fina PKI participants, shall include:

• name and surname of the Signatory; • OIB of the Signatory; • Signatory's association with the business entity; • place of residence; • country of residence; • e-mail of the Signatory.

9.4.4. Responsibility to protect private information

Fina, as the certification service provider, and External sub-contracted RA shall be responsible for personal data protection in accordance to the provisions of Personal Data Protection Act [9] and other regulations, in particular those governing the personal data protection and data secrecy in the Republic of Croatia.

9.4.5. Notice and consent to use private information

As the certification service provider, Fina shall be authorised to use personal data, except for the purposes of meeting legal or contractual obligations under agreements governing certification services, only pursuant to a written consent of the signatory, custodian or subscriber to the time-stamping service. The signatory and custodian, or subscriber to the time-stamping service, shall give Fina their consent for the use of personal data in the certificate application or in the application for time-stamping services.

9.4.6. Disclosure pursuant to judicial or administrative process

As the certification service provider, Fina shall not give access to data referred to in Sections 9.3.1. and 9.4.2. of this CPSNQC document, unless required by legal regulations, Certificate



Policy [36] or requested in writing by the competent court, administrative or other competent state authority.

9.4.7. Other information disclosure circumstances

No stipulations.

9.5. Intellectual property rights

Certificate Policy [36], Time-Stamping Service Policy [37], as well as other Fina's documentation posted on the web-pages of Fina RDC 2015, Fina RDC-TDU 2015 and Fina QTSA repository referred to in Section 2.2. of the CPSNQC document shall be the property of Fina and its unauthorised use shall not be allowed without Fina's explicit authorisation.

Each object or work which is a subject of an intellectual property right, related to the provision of certification services falling within the scope of the Certificate Policy [36] and Time-Stamping Service Policy [37], regardless whether it belongs to Fina or another participant, shall be protected pursuant to relevant regulations.

Third party software used in Fina PKI shall be used in accordance with the provisions concerning the right of use.

PKI participants shall abide by intellectual property rights.

9.6. Representations and warranties

9.6.1. CA representations and warranties

As the certification service provider, when providing services of issuance and management of life cycle of non-qualified certificates Fina shall apply the Act [1], [2] and [3], subordinate legislation [4], [5] and [6] adopted pursuant to the Act [1], [2] and [3], binding international standards and recommendations, Certificate Policy [36] and this CPSNQC. When providing the certification services falling within the scope of this CPSNQC document Fina shall also apply other acts set out in this CPSNQC document.

Fina shall post the acts intended for publication on web pages of the corresponding Fina CA repository referred to in Section 2.2. of the CPSNQC document.

Fina shall post all communications and information concerning changes in the operation which affect or may affect Fina PKI participants in any way on the listed web pages of the repository.

Fina CAs shall issue non-qualified certificates aligned with the X.509 v3 standard [32] and IETF RFC 5280 [23] recommendation, in accordance with the provisions of the HRN ETSI/EN 319 411-3 [12] standardisation document.



When providing the service of issuance and management of life cycle of non-qualified certificates Fina CAs shall comply with all the requirements and provisions stipulated in the Certificate policy [36] and this CPSNQC document.

Fina CAs shall perform the services falling within the scope of this CPSNQC document with due professional care.

Prior to initiating the generation of certificate, Fina CAs shall verify the electronically signed registered subscriber data provided by the RA Network. This is to identify the RA/LRA as a sender and check the integrity of received registered subscriber data,

Fina CAs shall issue a certificate based on activities of reliable identification of Signatory or Custodian, business entity, person authorized to represent the legal person and other data about the business entity.

If the subscriber agrees to the publication of its certificate, Fina CA shall post the issued certificate in a public directory of the corresponding FINA repository as set out in Section 2.2. of the CPSNQC document.

Pursuant to the application of a natural person and/or business entity, after the stipulated procedure, Fina CA shall revoke or suspend the certificate and publish it on the Certificate Revocation List.

Fina shall suspend the certificate and publish the suspended certificates on the Certificate Revocation List, and notify the pertaining subscriber thereof:

• if Fina has the proof or reasonable doubt that the private key has been compromised; • if Fina is of the opinion that an omission was made during the issuance of the

certificate.

Fina CA shall ensure the publication of the correct Certificate Revocation List.

In its business operations Fina CA shall apply organisational and technical measures for the protection of keys and certificates, as well as the protection of the information pertaining to the Signatory of Custodian, business entity or authorised representative, which are deemed as confidential pursuant to Section 9.4. of the CPSNQC document. As the certification service provider, Fina shall use such information only for the purposes of certification services falling within the scope of the CPSNQC document.

As the certification service provider, Fina shall ensure that the RA Network operates in accordance with the provisions of the Act [1], [2] and [3], subordinate legislation adopted pursuant to the Act [4, [5] and [6], Certificate Policy [36], CPSNQC document, and other FINA acts relating to the provision of certification services. The operation of External sub-contracted RAs shall be regulated by a registration service agreement.

Fina CA shall ensure a method for proving that the certification subject possesses a private key whose pertaining public key shall be delivered for certification.



Fina CA shall ensure conditions for secure generation of the pair of Subject's keys and that the private key secrecy is ensured in accordance with the provisions of the HRN ETSI/EN 319 411-3 [12] standard for all certificates for which key pairs are generated in Fina CA, i.e. for which key pairs are generated at the Subscriber's site by the Signatory or Custodian, under remote supervision of Fina CA, or sub-contracted RA. Fina CA shall stipulate the conditions for key pair generation performed by the Custodian at the Subscriber's site ensuring the secrecy of the private key, in accordance with the provisions of the HRN ETSI/EN 319 411-3 [12] standard.

Fina CA shall ensure that the corresponding SSCD is securely delivered to the RA Network to be delivered to the Signatory or Custodian, in accordance with the HRN ETSI/EN 319 411-3 [12] standard, if the use of SSCD device is determined by the type of the certificate requested. The procedure in cases when Fina CA issues certificates on SSCD devices for Signatories registered by an External sub-contracted RA and the SSCD device delivery procedure shall be regulated by a registration service agreement between Fina and the External RA.

Fina CA shall carry out the required security measures for protection of premises and equipment of the certification system.

In accordance with best business practices, Fina CA shall ensure unhindered operation and maximum possible availability of certification services, except in the following cases:

• system maintenance planned in advance; • unplanned stoppage due to the removal of the consequences of the system failure; • unplanned stoppage due to infrastructure failure not within the Fina's area of

competence; • unavailability due to force majeure or exceptional events.

Fina CA and Fina QTSA shall resolve stoppages and errors in system operations as soon as possible.

Fina, as the certification service provider, shall plan maintenance and further development of the certification system in accordance with recognised standards and technological developments.

In the event of a disruption in operations of an individual Fina CA, Fina shall act in accordance with Section 5.8. of this CPSNQC document.

Fina, as the certification service provider, shall be liable for damage caused to subscribers or relying parties exercising reasonable reliance in the certificate in the event that it does not meet the following requirements:

• verification of data accuracy and integrity at the time of subscriber registration and that, depending on the type of requested certificate, the issued certificate contains all the components described in Chapter 7.1. of the CPSNQC document;

• ensures that the Signatory or Custodian, at the time of certificate issuance, had possession of the private key whose corresponding public key is installed in the



certificate or, insofar as the key pairs are generated at Fina CA or Fina LRA site, ensures a secure way of generating and delivery of a private key and corresponding activation data;

• revocation or suspension of the certificate, and publication of its revocation or suspension status in the corresponding Certificate Revocation List upon the Subscriber's request, unless Fina CA demonstrates that it acted with due care.

Fina, as the certification service provider, shall be liable for damage caused by non-compliance with the relevant provisions of this CPSNQC document in the RA network operation. This responsibility of Fina towards the External sub-contracted RAs shall be regulated by a registration service agreement.

9.6.2. RA representations and warranties

Obligations and responsibilities of Fina RA Network and the External sub-contracted RAs are as follows:

• carrying out the registration and identification procedures for natural persons and business entities in the manner stipulated by this CPSNQC document;

• keeping and protection of the data collected in the manner and in accordance with the legislation referred to in this CPSNQC document;

• forwarding integral, accurate and verified data about subscribers and the Subject to Fina CA for further processing;

• archiving the requests and collected documentation in the manner stipulated by this CPSNQC document;

• insuring the archived Subscriber data against loss or confidentiality, integrity and accessibility violation as laid down in this CPSNQC document.

• insuring the SSCD device and its protected delivery to the Signatory or Custodian, in accordance with this CPSNQC document, if the use of an SSCD device is determined by the type of the certificate requested.

In addition to these obligations, External sub-contracted RA must also abide by the obligations arising from agreements on provision of registration services concluded with Fina.

9.6.3. Subscriber representations and warranties

The Subscriber shall: • introduce itself during the registration process as stipulated in Chapter 3 and in

Section 4.1.2.2. of this CPSNQC document; • carefully use and keep the means for generating electronic signature, private keys

and activation data, and use them in accordance with the provisions of the Act [1], [2] and [3], corresponding regulations and this CPSNQC document;



• undertake appropriate protection measures for the electronic signature creation

device, private keys and activation data against unauthorised access and use in accordance with Chapter 6. of this CPSNQC document;

• request, as soon as possible, the revocation or the suspension of their certificate in case of private key compromise, the loss or damage to the electronic signature creation device, private key and activation data in accordance with Section 4.9 of this CPSNQC document;

• submit all necessary data and information to the registration office about changes that affect or may affect the accuracy of the electronic signature within two days from the resulting change, in accordance with Section 4.8 of this CPSNQC document;

• in case the time-stamping service is used, verify Fina QTSA 2015 electronic signature on the received time stamp and check Fina QTSA 2015 certificate validity.

• act in accordance with all other provisions of this CPSNQC document which refer to Subscriber obligations.

The business entity or person authorised for representation of the business entity shall as soon as possible request business certificate revocation 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, or request a change to the custodian data insofar as it is a business certificate issued for IT equipment.

The Subscriber shall be responsible for irregularities resulting due to non-fulfilment of obligations determined in the above provisions referred to in this Section.

The Subscriber who fails to act in accordance with the aforementioned obligations assumed and the obligations under the certification service agreement shall have its certificate revoked, i.e. the use of time-stamping service prevented, and it shall lose all rights arising from the agreement.

9.6.4. Relying party representations and warranties

A Relying Party shall make an autonomous and conscious decision on reasonable certificate or time-stamp reliance.

Reasonable reliance is deemed a decision by the Relying Party to rely on a certificate or a time-stamp if at the time of reliance the Relying Party:

• used the certificate for the purposes stipulated in the Certificate Policy [36] and this CPSNQC document under the circumstances in which the reliance is reasonable and in good faith, and under the circumstances known or which should be known to the Relying Party prior to relying on a certificate;

• checked whether the certificate has expired, has been revoked or suspended at the time of reliance, which should be ascertained by the Relying Party by checking the certificate's status on the basis of the last issued CRL list as stipulated in this CPSNQC document;



• checked whether all Subject's identity data in the certificate are properly displayed in

the application which can be trusted; • in the event of electronic signature verification, check if the electronic signature was

created by a private key corresponding to the public key in the Subscriber's certificate within the Certificate Validity Period;

• in the event of time-stamp use, verified the time-stamp signature and on the last issued CRL list checked the revocation status of the Fina QTSA 2015 certificate with whose pertaining private TSU key the time stamp was signed.

The use of the public key and certificate by a Relying party is described in Section 4.5.2., and the requirements for checking the revocation status of the certificate are set out in Section 4.9.6. of this CPSNQC document.

The Relying party who, by not complying with the regulations, Certificate Policy [36], Qualified Time-Stamping Service Policy [37] and in contravention to the previously set obligations and responsibilities under this Section of the CPSNQC document, relied on an invalid certificate (revoked, expired or suspended certificate), or in incorrect time-stamp, shall bear all the risks connected to such certificate or time-stamp reliance .

A Relying Party shall bear all the certificate or time stamp reliance risks if it is aware of or has a reason to believe that there are facts that may cause a personal or business damage due to the certificate or time stamp use.

9.6.5. Representations and warranties of other participants

No stipulations.

9.6.6. QTSA obligations and responsibilities

As the time-stamping service provider, when issuing time-stamps Fina shall apply the Act [1], [2] and [3], subordinate legislation [4], [5] and [6] adopted pursuant to the Act [1], [2] and [3], binding international standards and recommendations, Certificate Policy [37] and this CPSNQC. When providing the time-stamping services falling within the scope of this CPSNQC document Fina shall also apply other acts set out in this CPSNQC document.

As the time-stamping service provider, Fina shall be fully responsible for the provision of time-stamping services and for secure and correct operation of TSU units creating the time-stamp.

Fina shall post the acts intended for publication on web pages of the Fina QTSA repository referred to in Section 2.2.3. of this CPSNQC document.

Fina QTSA shall post all communications and information concerning changes in the operation which affect or may affect Fina PKI participants in any way on the listed web pages of the repository.



Fina QTSA 2015 shall issue time-stamps aligned with the IETF RFC 3161 [20] recommendation, and in accordance with the provisions of the HRN ETSI/EN 102 023 [17] standardisation document.

Fina QTSA 2015 shall be responsible to ensure the accuracy of UTC time data integrated in the time-stamp within the deviation limits set out in Section 1.2. of the Qualified Time-Stamping Service Policy [37].

During the provision of time-stamping services Fina QTSA shall comply with all the requirements and provisions stipulated in the Qualified Time-Stamping Service Policy [37] and this CPSNQC document.

Fina QTSA shall perform the services falling within the scope of this CPSNQC document with due professional care.

In its business operations Fina QTSA shall apply organisational and technical measures for the protection of the information pertaining to the Subscriber, business entity or authorised representative, which are deemed as confidential pursuant to Section 9.4 of the CPSNQC document. As the time-stamping service provider, Fina shall use such information only for the purposes of certification services falling within the scope of the CPSNQC document.

Fina QTSA shall carry out the required security measures for protection of premises and equipment of the time-stamping system.

In accordance with best business practices, Fina QTSA shall ensure unhindered operation and maximum possible availability of time-stamping services, except in the following cases:

• system maintenance planned in advance; • unplanned stoppage due to the removal of the consequences of the system failure; • unplanned stoppage due to infrastructure failure not within the Fina's area of

competence; • unavailability due to force majeure or exceptional events.

Fina QTSA shall resolve stoppages and errors in system operations as soon as possible.

Fina, as the time-stamping service provider, shall plan maintenance and further development of the time-stamping system in accordance with recognised standards and technological developments.

In the event of a disruption in operations of Fina QTSA, Fina shall act in accordance with Section 5.8. of this CPSNQC document.

Fina, as the time-stamping service provider, shall be liable for damage caused by non-compliance with the relevant provisions of this CPSNQC document in the Fina RA network operation.



9.7. Disclaimers of warranties Except as expressly provided for in Section 9.6. of this CPSNQC document with respect to Fina, Fina, as a Certification Service Provider, shall not be held liable for any other warranty or responsibility, particularly not in case of Fina's liability under given warranties resulting from a violation of other participants' warranties and responsibilities listed in Section 9.6. of this CPSNQC document.

Fina shall not be liable for the use of certificates or time-stamps issued by another Certification Service Provider or for the use of its CA certificate outside the Fina CA domain.

Fina shall not be liable for damages, including indirect or special damages, damages due to accident, damages due to disaster consequences, or loss of profit, loss of data or other indirect damages arising out of certification services:

• for damages suffered in the period from the certificate revocation to issuance of the next CRL;

• for damages due to unauthorised use of Subscribers' keys and certificates; • for damages arising out of the use of time-stamping services on behalf of the

Subscriber, without the Subscriber's authorisation; • for damages occuring due to the use of certicate in applications not allowed under the

Certificate policy and this CPSNQC document; • for damages caused by false or negligent use of the certificate or CRL; • for damages occurring as a result of deficiencies and errors in the Subject's and

Relying Party's software and hardware . RA Network shall not be liable for damages, including indirect and special damages, damages resulting from an accident, disaster consequences, loss of profit, loss of data or other indirect damages related to certification services occurred as a result of false data provision and Subscriber's false identification during the identification and clearance procedure if the data were checked in accordance with the procedures referred to in this CPSNQC document and the requirements referred to in the Certificate Policy [36].

9.8. Limitations of liability

Fina's total financial liability for issued non-qualified certificates issued according to the Certificate Policy and this CPSNQC document, and for transactions carried out in reliance on certificates issued in such a way shall amount to HRK 1,500,000 at most.

Unless provided in a separate agreement or otherwise, Fina's maximum financial liability towards a Subscriber and Relying Party, showing reasonable reliance in the non-qualified certificate, shall be limited in accordance to recommended financial limits set out in Table 1.5 under Section 1.4. of this CPSNQC document as shown in Table 9.1.



Certificate category FINA's maximum financial liability

By category By transaction Total

Standard level security non-qualified certificate up to HRK 100,000 up to HRK 8,000

HRK 1,500,000 Medium level security non-qualified certificate up to HRK 600,000 up to HRK 80,000

High level security non-qualified certificate up to HRK 800,000 up to HRK 400,000

Table 9.1 FINA's maximum financial liability for non-qualified certificate

FINA's maximum financial liability towards the Subscriber and the Relying party who reasonably relies on the time-stamp shall amount to a maximum of HRK 20,000.00 per transaction.

Fina's total financial liability for time-stamps issued in accordance with this CPSNQC document and for transactions carried out in reliance on time-stamping made in such a way shall amount to HRK 100,000.00 at most.

9.9. Indemnities

Each participant shall be liable to the damaged party for damages caused by failing to comply with the provisions of the Certificate Policy [36], this CPSNQC document and relevant regulations in force.

The Signatory, that is, natural or legal person on behalf of which the Signatory acts and which is represented by the Signatory, shall be liable to the damaged party, that is, any other participant if it obtains and uses the certificate issued by Fina CA based on false data provided in the Certificate Application.

A Relying party shall be liable to a damaged or any other participant if it relies on an issued certificate without checking its validity as described in Section 9.6.4 of this CPSNQC document, or uses it contrary to the purposes set out in the Certificate Policy [36] and this CPSNQC document.

Fina shall be liable to the person relying on the certificate only if such liability has been clearly set out in an agreement, the Certificate Policy [36], this CPSNQC document or Croatian legislation.



9.10. Term and termination

9.10.1. Term

This CPSNQC document shall be valid until a new CPSNQC document comes into force or until its termination is posted. New version of the CPSNQC document or its termination shall be posted internally in Fina CA and Fina QTSA and in Fina central RA. Adapted version of the new CPSNQC document which does not contain confidential data may be posted on the web pages of Fina RDC 2015 and Fina RDC-TDU 2015 repository referred to in Section 2.2 of this CPSNQC document. The new CPSNQC document shall have an indicated effective date. The new CPSNQC document shall be assigned a new version and it shall contain indicated modifications made to it.

Fina PMA shall decide on the need to amend the CPSNQC document, posting a new version of the document and the number of its version.

9.10.2. Termination

Upon entering into force of the new version of the CPSNQC document, all certificates issued according to this document shall be in line with the stipulations contained therein, which shall not be replaced by the stipulations of the new version of the CPSNQC document in terms of their meaning.

This CPSNQC document termination shall not be bound by nor shall it affect the validity of certificates issued under this document.

Fina may amend individual provisions of the CPSNQC document in force as specified in Section 9.12. of the Certificate Policy [36] and this CPSNQC document.

9.10.3. Effect of termination and survival

Upon entry into force of the new CPSNQC document, the provisions laid down in this document shall apply to all certificates issued from that date.

New CPSNQC document shall not affect the validity of certificates issued based on the previous CPSNQC documents. Certificates issued using the previous CPSNQC shall be valid until their expiry whereupon they may be renewed by applying the provision of the new CPSNQC document.

9.11. Individual notices and communication with participants

Individual notices and other official communication shall be made in writing and sent in hard or soft copy.



Contact data for delivery of correspondence to Fina

Mailing address: FINA e-Business Centre (for Fina RDC) Ulica grada Vukovara 70 10000 Zagreb Croatia

E-mail: [email protected]

Fax: +385-1-6304-081

Table 9.2. Contact data for delivery of correspondence to Fina

In the event of email delivery, correspondence must be signed with the advanced electronic signature of the sender.

9.12. Amendments

9.12.1. Procedure for amendment

CPSNQC document shall be revised where necessary and after each modification of the Certificate policy [36]. Fina PMA shall be responsible for all amendments. Fina PMA may correct spelling mistakes, change contact data and make other minor corrections not materially affecting the participants without notice to the participants and amendments to the version of the document. All amendments to the CPSNQC document that may materially affect the participants shall be notified to the participants. Such amendments shall warrant the change of the OID of the CPSNQC document.

All participants may send a letter to the Fina PMA contact address referred to in Section 1.4 of this CPSNQC document, containing the proposal for corrections or for the amendment to this document. The letter shall include contact details of the person sending the modification. Upon examination, Fina may accept, adjust or reject proposed modifications.

9.12.2. Notification mechanism and periods

CPSNQC is an internal Fina document and shall not be published. The version of the CPSNQC document not containing confidential data may be published. This document shall be posted on the web pages of the Fina CA repository referred to in Section 2.2. of this CPSNQC document.




9.12.3. Circumstances under which OID must be changed

Minor amendments to the CPSNQC document contents that do not materially affect the participants shall not require the change of document OID.

Major amendments to the CPSNQC document that may affect the participants shall require the change of the CPSNQC document OID. As a rule, Fina PMA incrementally determines new OID for new versions of documents.

9.13. Dispute resolution provisions

In case of dispute or disagreement between the participants due to actions and/or procedures regarding certification in accordance with this CPSNQC document, 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.

The Signatory, that is, natural or legal person on behalf of which the Signatory acts and which is represented by the Signatory may file a complaint with Fina, should it consider that in its case the service content departs from the agreed one. Fina shall reply to the complaint. Complaint and the reply thereto shall be filed in hard or soft copy form as described under Section 9.11. of this CPSNQC document.

In case of dispute or disagreement between Fina as a Certification Service Provider pursuant to this CPSNQC document and the Signatory, that is, natural or legal person on behalf of which the Signatory acts and which is represented by the Signatory, in relation to the complaint regarding an alleged discrepancy of the service contents with respect to the agreed one, they shall try to reach an amicable solution. Otherwise, the matter shall be resolved by the competent court in Zagreb by application of Croatian law.

In case of dispute or disagreement between Fina, as a Certification Service Provider pursuant to this CPSNQC document, and the External sub-contracted RA, the dispute resolution shall be regulated by mutual agreement.

9.14. Governing law

The interpretation of the provisions of this CPSNQC document shall be governed by the Electronic Signature Act [1], [2] and [3], subordinate legislation[4], [5], [6] and [7] adopted pursuant to that Act, provisions of the Certificate Policy [36], i.e. Qualified Time-Stamping Service Policy [37], and regulations, standards and recommendations referred to in these documents.

9.15. Compliance with applicable law

This CPSNQC document and certification services provision covered in this CPSNQC document shall be in accordance with the regulations referred to in Section 9.14. of this CPSNQC document.



9.16. Miscellaneous provisions Fina, as a Certification Service Provider, may enter into an additional agreement with Fina PKI participants, provided that it is not contrary to law.

Fina shall ensure that the agreements concluded contain the appropriate provisions aligned with the provisions of this CPSNQC document, Certificate Policy [36], i.e. Qualified Time-Stamping Service Policy [37], and that these agreements allow the parties to protect their interests in accordance with the Certificate Policy [36], i.e. Qualified Time-Stamping Service Policy [37].