ommfidesp and ps for ertificatesand qualified entral · 2020-03-25 · ommfides-p-and- ps-for-...

Commfides-CP-and-CPS-for-Certificates-and-EU-Qualified-Certificates-Legal-Person-Central

Commfides Norge AS Postal address: PO Box 405, 1327 Lysaker Tel.: +47 21 55 62 60 E-mail: [email protected] Visitor address: Fornebuveien 1, 1366 Lysaker Business number: 988 312 495

Commfides-CP-and-CPS-for-Certificates-and-EU-Qualified-

Certificates-Legal-Person-Central

Certificate Policy and Certification Practice Statement for certificates signed by a subordinate CA

certificate that is signed by CA root certificate“CPN RootCA SHA256 Class 3”

Certificate Policy Identifier: Certificate Policy CP/CPS-Version

2.16.578.1.29.13.10.1.1 ETSI EN 319 411-1 NCP+ (for legal person)1) Version 1.1 Date 01.04.2020

2.16.578.1.29.13.11.1.1 ETSI EN 319 411-2 QCP-l-qscd (for legal person) 1)2) Version 1.1 Date 01.04.2020

2.16.578.1.29.13.12.1.1 ETSI EN 319 411-1 NCP+ (for legal person) 1) Version 1.1 Date 01.04.2020

2.16.578.1.29.13.20.1.1 ETSI EN 319 411-1 NCP (for legal person) 1) Version 1.1 Date 01.04.2020

2.16.578.1.29.13.21.1.1 ETSI EN 319 411-2 QCP-l (for legal person) 1)3) Version 1.1 Date 01.04.2020

2.16.578.1.29.13.22.1.1 ETSI EN 319 411-1 NCP (for legal person) 1) Version 1.1 Date 01.04.2020

2.16.578.1.29.13.30.1.1 ETSI EN 319 411-1 LCP (for legal person) 1) Version 1.1 Date 01.04.2020



1) Signed by CPN Enterprise SHA256 CLASS 3 2) Policy for EU qualified certificates issued to legal persons offering the level of quality defined in

Regulation (EU) N° 910/2014 [i.1] for EU qualified certificates and requiring the use of a Qualified

Signature Creation Device (QSCD). 3) Policy for EU qualified certificates issued to legal persons (QCP-l) offering the level of quality defined in

Regulation (EU) N° 910/2014 [i.1] for EU qualified certificates.

PUBLIC

Document ID: CN-CP-CPS-05


Commfides Norge AS

History of change

Version Date Status Description

1.0 (for

all OIDs)

21.11.2017 Approved Initial version approved by the Commfides Certificate

Advisory Board (Commfides CAB).

1.1 (for

all OIDs)

01.04.2020 Approved Added sentence in section "4.10 Certificate Status Services"

regarding CRL and OCSP.

In “Appendix 3, Commfides Certificate Profiles” the sha256

fingerprints and url links to root and subordinate CA is

included.

The EKU key usage Client Authentication (1.3.6.1.5.5.7.3.2)

for non-repudiation certificates and encryption-certificates

was removed (Appendix 3)

Removed the "2.5.29.28" in section "7.2.2 CRL and CRL

Entry Extensions"


Commfides Norge AS

Innholdsfortegnelse

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

1.1 Overview ............................................................................................................................................ 13

1.2 Document Name and Identification ................................................................................................... 18

1.3 PKI Participants ................................................................................................................................... 19

1.3.1 Certification Authorities .............................................................................................................. 19

1.3.2 Registration Authorities ............................................................................................................... 20

1.3.3 Subscribers (End Entities) ............................................................................................................ 21

1.3.4 Relying Parties ............................................................................................................................. 22

1.3.5 Other Participants ....................................................................................................................... 24

1.4 Certificate usage ................................................................................................................................. 24

1.4.1 Appropriate Certificate Uses ....................................................................................................... 24

1.4.2 Prohibited Certificate Uses .......................................................................................................... 24

1.5 Policy Administration .......................................................................................................................... 25

1.5.1 Organization Administering the Document ................................................................................. 25

1.5.2 Contact Person ............................................................................................................................ 25

1.5.3 Person Determining CPS Suitability for the Policy ....................................................................... 25

1.5.4 CPS approval procedures ............................................................................................................. 25

1.6 Definitions and Acronyms .................................................................................................................. 26

1.6.1 Acronyms ..................................................................................................................................... 32

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

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

2.2 Publication of Certification Information ............................................................................................. 33

2.3 Time or Frequency of Publication ...................................................................................................... 34

2.4 Access Controls on Repositories ......................................................................................................... 34

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

3.1 Naming ............................................................................................................................................... 35

3.1.1 Types of Names ........................................................................................................................... 35

3.1.2 Need for Names to be Meaningful .............................................................................................. 36

3.1.3 Anonymity or Pseudonymity of Subscribers ................................................................................ 36

3.1.4 Rules for Interpreting Various Name Forms ................................................................................ 36

3.1.5 Uniqueness of Names ................................................................................................................. 36


Commfides Norge AS

3.1.6 Recognition, Authentication, and Role of Trademarks ................................................................ 36

3.2 Initial Identity Validation .................................................................................................................... 37

3.2.1 Method to Prove Possession of Private Key ................................................................................ 41

3.2.2 Authentication of Organization Identity ...................................................................................... 41

3.2.3 Authentication of Individual Identity ........................................................................................... 41

3.2.4 Non-Verified Subscriber Information .......................................................................................... 41

3.2.5 Validation of Authority ................................................................................................................ 41

3.2.6 Criteria for Interoperation ........................................................................................................... 41

3.3 Identification and Authentication for Re-Key Requests ...................................................................... 42

3.3.1 Identification and Authentication for Routine Re-Key ................................................................. 42

3.3.2 Identification and Authentication for Re-Key after Revocation ................................................... 42

3.4 Identification and Authentication for Revocation Request ................................................................. 42

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

4.1 Certificate Application ........................................................................................................................ 43

4.1.1 Who can Submit a Certificate Application ................................................................................... 43

4.1.2 Enrollment Process and Responsibilities ..................................................................................... 43

4.2 Certificate Application Processing ...................................................................................................... 44

4.2.1 Performing Identification and Authentication Functions ............................................................ 44

4.2.2 Approval or Rejection of Certificate Applications ........................................................................ 44

4.2.3 Time to Process Certificate Applications ..................................................................................... 44

4.3 Certificate Issuance ............................................................................................................................ 45

4.3.1 CA Actions during Certificate Issuance ........................................................................................ 46

4.3.2 Notification to Subscriber by the CA of Issuance of Certificate ................................................... 46

4.4 Certificate Acceptance ....................................................................................................................... 46

4.4.1 Conduct Constituting Certificate Acceptance.............................................................................. 47

4.4.2 Publication of the Certificate by the CA ...................................................................................... 47

4.4.3 Notification of Certificate Issuance by the CA to Other Entities .................................................. 47

4.5 Key Pair and Certificate Usage ............................................................................................................ 48

4.5.1 Subscriber Private Key and Certificate Usage .............................................................................. 48

4.5.2 Relying Party Public Key and Certificate Usage............................................................................ 48

4.6 Certificate Renewal ............................................................................................................................ 49

4.6.1 Circumstance for Certificate Renewal ......................................................................................... 49


Commfides Norge AS

4.6.2 Who May Request Renewal ........................................................................................................ 49

4.6.3 Processing Certificate Renewal Requests .................................................................................... 49

4.6.4 Notification of New Certificate Issuance to Subscriber ............................................................... 49

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

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

4.6.7 Notification of certificate issuance by the CA to other entities ................................................... 50

4.7 Certificate Re-Key ............................................................................................................................... 51

4.7.1 Circumstance for Certificate Re-Key ............................................................................................ 51

4.7.2 Who May Request Certification of a New Public Key .................................................................. 51

4.7.3 Processing Certificate Re-Keying Requests .................................................................................. 51


4.7.5 Conduct Constituting Acceptance of a Re-Keyed Certificate ....................................................... 51

4.7.6 Publication of the Re-Keyed Certificate by the CA ....................................................................... 51


4.8 Certificate Modification ...................................................................................................................... 52

4.8.1 Circumstance for Certificate Modification................................................................................... 52

4.8.2 Who May Request Certificate Modification ................................................................................ 52

4.8.3 Processing Certificate Modification Requests ............................................................................. 52


4.8.5 Conduct Constituting Acceptance of Modified Certificate .......................................................... 52

4.8.6 Publication of the Modified Certificate by the CA ....................................................................... 52


4.9 Certificate Revocation and Suspension .............................................................................................. 53

4.9.1 Circumstances for Revocation ..................................................................................................... 53

4.9.2 Who can Request Revocation ...................................................................................................... 54

4.9.3 Procedure for Revocation Request .............................................................................................. 54

4.9.4 Revocation Request Grace Period ............................................................................................... 55

4.9.5 Time Within which CA Must Process the Revocation Request .................................................... 55

4.9.6 Revocation Checking Requirement for Relying Parties ................................................................ 55

4.9.7 CRL Issuance Frequency (if applicable) ....................................................................................... 55

4.9.8 Maximum Latency for CRLs (if applicable)................................................................................... 55

4.9.9 On-Line Revocation/Status Checking Availability ........................................................................ 55


Commfides Norge AS

4.9.10 On-Line Revocation Checking Requirements............................................................................. 56

4.9.11 Other Forms of Revocation Advertisements Available .............................................................. 56

4.9.12 Special Requirements Re-Key Compromise ............................................................................... 56

4.9.13 Circumstances for Suspension ................................................................................................... 56

4.9.14 Who can Request Suspension ................................................................................................... 56

4.9.15 Procedure for Suspension Request ........................................................................................... 56

4.9.16 Limits on Suspension Period...................................................................................................... 56

4.10 Certificate Status Services ................................................................................................................ 57

4.10.1 Operational Characteristics ....................................................................................................... 57

4.10.2 Service Availability ..................................................................................................................... 57

4.10.3 Optional Features ...................................................................................................................... 57

4.11 End of Subscription .......................................................................................................................... 58

4.12 Key Escrow and Recovery ................................................................................................................. 58

4.12.1 Key Escrow and Recovery Policy and Practices .......................................................................... 58

4.12.2 Session Key Encapsulation and Recovery Policy and Practices .................................................. 58

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

5.1 Physical Controls ................................................................................................................................ 60

5.1.1 Site Location and Construction ................................................................................................... 60

5.1.2 Physical Access ............................................................................................................................ 60

5.1.3 Power and Air Conditioning......................................................................................................... 61

5.1.4 Water Exposures ......................................................................................................................... 61

5.1.5 Fire Prevention and Protection.................................................................................................... 61

5.1.6 Media Storage ............................................................................................................................. 61

5.1.7 Waste Disposal ............................................................................................................................ 62

5.1.8 Off-Site Backup ............................................................................................................................ 62

5.2 Procedural Controls ............................................................................................................................ 62

5.2.1 Trusted Roles ............................................................................................................................... 62

5.2.2 Number of Persons Required per Task ........................................................................................ 62

5.2.3 Identification and Authentication for Each Role .......................................................................... 63

5.2.4 Roles Requiring Separation of Duties .......................................................................................... 63

5.3 Personnel Controls ............................................................................................................................. 64

5.3.1 Qualifications, Experience, and Clearance Requirements ........................................................... 65


Commfides Norge AS

5.3.2 Background Check Procedures .................................................................................................... 65

5.3.3 Training Requirements ................................................................................................................ 65

5.3.4 Retraining Frequency and Requirements .................................................................................... 66

5.3.5 Job Rotation Frequency and Sequence ....................................................................................... 66

5.3.6 Sanctions for Unauthorized Actions ............................................................................................ 66

5.3.7 Independent Contractor Requirements ...................................................................................... 66

5.3.8 Documentation Supplied to Personnel ........................................................................................ 66

5.4 Audit Logging Procedures................................................................................................................... 67

5.4.1 Types of Events Recorded ............................................................................................................ 69

5.4.2 Frequency of Processing Log ....................................................................................................... 69

5.4.3 Retention Period for Audit Log .................................................................................................... 69

5.4.4 Protection of Audit Log ............................................................................................................... 69

5.4.5 Audit Log Backup Procedures ...................................................................................................... 70

5.4.6 Audit Collection System (Internal vs. External) ............................................................................ 70

5.4.7 Notification to Event-Causing Subject ......................................................................................... 70

5.4.8 Vulnerability Assessments ........................................................................................................... 70

5.5 Records Archival ................................................................................................................................. 71

5.5.1 Types of Records Archived ........................................................................................................... 71

5.5.2 Retention Period for Archive ....................................................................................................... 71

5.5.3 Protection of Archive ................................................................................................................... 71

5.5.4 Archive Backup Procedures ......................................................................................................... 71

5.5.5 Requirements for Time-Stamping of Records .............................................................................. 72

5.5.6 Archive Collection System (Internal or External) ......................................................................... 72

5.5.7 Procedures to Obtain and Verify Archive Information ................................................................. 72

5.6 Key Changeover .................................................................................................................................. 72

5.7 Compromise and Disaster Recovery ................................................................................................... 73

5.7.1 Incident and Compromise Handling Procedures ......................................................................... 73

5.7.2 Computing Resources, Software, and/or Data are Corrupted ..................................................... 74

5.7.3 Entity Private Key Compromise Procedures ................................................................................ 74

5.7.4 Business Continuity Capabilities after a Disaster ......................................................................... 75

5.8 CA or RA Termination ......................................................................................................................... 76

6. TECHNICAL SECURITY CONTROLS ................................................................................................. 77


Commfides Norge AS

6.1 Key Pair Generation and Installation .................................................................................................. 77

Certificate generation; ......................................................................................................................... 77

6.1.1 Key Pair Generation ..................................................................................................................... 79

6.1.2 Private Key Delivery to Subscriber ............................................................................................... 79

6.1.3 Public Key Delivery to Certificate Issuer ...................................................................................... 79

6.1.4 CA Public Key Delivery to Relying Parties .................................................................................... 79

6.1.5 Key Sizes ...................................................................................................................................... 79

6.1.6 Public Key Parameters Generation and Quality Checking ........................................................... 80

6.1.7 Key Usage Purposes (as per X.509 v3 key usage field) ................................................................ 80

6.2 Private Key Protection and Cryptographic Module Engineering Controls .......................................... 81

6.2.1 Cryptographic Module Standards and Controls .......................................................................... 81

6.2.2 Private Key (n out of m) Multi-Person Control ............................................................................ 81

6.2.3 Private Key Escrow ...................................................................................................................... 82

6.2.4 Private Key Backup ...................................................................................................................... 82

6.2.5 Private Key Archival ..................................................................................................................... 82

6.2.6 Private Key Transfer into or from a Cryptographic Module ......................................................... 82

6.2.7 Private Key Storage on Cryptographic Module ............................................................................ 82

6.2.8 Method of Activating Private Key ................................................................................................ 82

6.2.9 Method of Deactivating Private Key ............................................................................................ 83

6.2.10 Method of Destroying Private Key ............................................................................................. 83

6.2.11 Cryptographic Module Rating ................................................................................................... 83

6.3 Other Aspects of Key Pair Management............................................................................................. 84

6.3.1 Public Key Archival ....................................................................................................................... 84

6.3.2 Certificate Operational Periods and Key Pair Usage Periods ....................................................... 84

6.4 Activation Data ................................................................................................................................... 85

6.4.1 Activation Data Generation and Installation................................................................................ 85

6.4.2 Activation Data Protection .......................................................................................................... 85

6.4.3 Other Aspects of Activation Data ................................................................................................ 85

6.5 Computer Security Controls ............................................................................................................... 86

6.5.1 Specific Computer Security Technical Requirements .................................................................. 86

6.5.2 Computer Security Rating ........................................................................................................... 86

6.6 Life Cycle Technical Controls............................................................................................................... 87


Commfides Norge AS

6.6.1 System Development Controls .................................................................................................... 87

6.6.2 Security Management Controls ................................................................................................... 87

6.6.3 Life Cycle Security Controls ......................................................................................................... 88

6.7 Network Security Controls ................................................................................................................. 89

6.8 Time-Stamping ................................................................................................................................... 89

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

7.1 Certificate Profile ................................................................................................................................ 90

7.1.1 Version Number(s) ...................................................................................................................... 90

7.1.2 Certificate Extensions .................................................................................................................. 90

7.1.3 Algorithm Object Identifiers ........................................................................................................ 90

7.1.4 Name Forms ................................................................................................................................ 90

7.1.5 Name Constraints ........................................................................................................................ 90

7.1.6 Certificate Policy Object Identifier ............................................................................................... 92

7.1.7 Usage of Policy Constraints Extension ......................................................................................... 93

7.1.8 Policy Qualifiers Syntax and Semantics ....................................................................................... 93

7.1.9 Processing Semantics for the Critical Certificate Policies Extension ............................................ 94

7.2 CRL Profile .......................................................................................................................................... 95

7.2.1 Version Number(s) ...................................................................................................................... 95

7.2.2 CRL and CRL Entry Extensions ..................................................................................................... 95

7.3 OCSP Profile ........................................................................................................................................ 96

7.3.1 Version Number(s) ...................................................................................................................... 96

7.3.2 OCSP Extensions .......................................................................................................................... 96

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS ........................................................................... 97

8.1 Frequency or Circumstances of Assessment ...................................................................................... 97

8.2 Identity/Qualifications of Assessor ..................................................................................................... 97

8.3 Assessor's Relationship to Assessed Entity ......................................................................................... 97

8.4 Topics Covered by Assessment ........................................................................................................... 98

8.5 Actions Taken as a Result of Deficiency .............................................................................................. 98

8.6 Communication of Results ................................................................................................................. 98

9. OTHER BUSINESS AND LEGAL MATTERS ........................................................................................ 99

9.1 Fees .................................................................................................................................................... 99

9.1.1 Certificate Issuance or Renewal Fees .......................................................................................... 99


Commfides Norge AS

9.1.2 Certificate Access Fees ................................................................................................................ 99

9.1.3 Revocation or Status Information Access Fees ............................................................................ 99

9.1.4 Fees for Other Services ............................................................................................................... 99

9.1.5 Refund Policy ............................................................................................................................... 99

9.2 Financial Responsibility .................................................................................................................... 100

9.2.1 Insurance Coverage ................................................................................................................... 100

9.2.2 Other Assets .............................................................................................................................. 100

9.2.3 Insurance or Warranty Coverage for End-Entities ..................................................................... 100

9.3 Confidentiality of Business Information ........................................................................................... 101

9.3.1 Scope of Confidential Information ............................................................................................ 101

9.3.2 Information Not Within the Scope of Confidential Information ................................................ 101

9.3.3 Responsibility to Protect Confidential Information ................................................................... 101

9.4 Privacy of Personal Information ....................................................................................................... 102

9.4.1 Privacy Plan ............................................................................................................................... 102

9.4.2 Information Treated as Private .................................................................................................. 102

9.4.3 Information not Deemed Private ............................................................................................... 103

9.4.4 Responsibility to Protect Private Information ............................................................................ 103

9.4.5 Notice and Consent to use Private Information ........................................................................ 103

9.4.6 Disclosure Pursuant to Judicial or Administrative Process ........................................................ 103

9.4.7 Other Information Disclosure Circumstances ............................................................................ 103

9.5 Intellectual Property Rights .............................................................................................................. 104

9.6 Representations and Warranties ...................................................................................................... 105

9.6.1 CA Representations and Warranties .......................................................................................... 105

9.6.2 RA Representations and Warranties .......................................................................................... 105

9.6.3 Subscriber Representations and Warranties ............................................................................. 105

9.6.4 Relying Party Representations and Warranties ......................................................................... 105

9.6.5 Representations and Warranties of other Participants ............................................................. 105

9.7 Disclaimers of Warranties................................................................................................................. 106

9.8 Limitations of Liability ...................................................................................................................... 106

9.9 Indemnities ...................................................................................................................................... 106

9.10 Term and Termination .................................................................................................................... 107

9.10.1 Term ........................................................................................................................................ 107


Commfides Norge AS

9.10.2 Termination ............................................................................................................................. 107

9.10.3 Effect of Termination and Survival ........................................................................................... 107

9.11 Individual Notices and Communications with Participants ............................................................ 107

9.12 Amendments .................................................................................................................................. 107

9.12.1 Procedure for Amendment ..................................................................................................... 108

9.12.2 Notification Mechanism and Period ........................................................................................ 108

9.12.3 Circumstances Under Which OID Must be Changed ............................................................... 108

9.13 Dispute Resolution Provisions ........................................................................................................ 108

9.14 Governing Law ................................................................................................................................ 109

9.15 Compliance with Applicable Law .................................................................................................... 109

9.16 Miscellaneous Provisions ............................................................................................................... 109

9.16.1 Entire Agreement .................................................................................................................... 109

9.16.2 Assignment .............................................................................................................................. 109

9.16.3 Severability .............................................................................................................................. 109

9.16.4 Enforcement (Attorneys' Fees and Waiver of Rights) .............................................................. 110

9.16.5 Force Majeure ......................................................................................................................... 110

9.17 Other Provisions ............................................................................................................................. 111

Appendix 1 ...................................................................................................................................... 113

Appendix 2 ...................................................................................................................................... 114

Appendix 3, Commfides Certificate Profiles ........................................................................................ 115


Commfides Norge AS

References [1] Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic

identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC.

[2] ETSI EN 319 401: "Electronic Signatures and Infrastructures (ESI); General Policy Requirements for Trust Service

Providers".

[3] ETSI EN 319 411-1: "Electronic Signatures and Infrastructures (ESI); Policy and security requirements for trust service

providers issuing certificates; Part 1: General requirements".

[4] ETSI EN 319 411-2: "Electronic Signatures and Infrastructures (ESI); Policy and security

requirements for Trust Service Providers issuing certificates; Part 2: Requirements for trust service

providers issuing EU qualified certificates".

[5] IETF RFC 3647: "Internet X.509 Public Key Infrastructure - Certificate Policy and Certification

Practices Framework".

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

systems Requirements.

[7] EVCG CA/Browser Forum (V1.6): "Guidelines for The Issuance and Management of Extended

Validation Certificates"

[8] BRG CA/Browser Forum (V1.3.0): "Baseline Requirements for the Issuance and Management of

Publicly-Trusted Certificates".

[9] Lov 14.april 2000 nr.31 om behandling av personopplysninger (personopplysningsloven)

[10] Forskrift 15.des 2000 nr.1265 om behandling av personopplysninger (personopplysningsforskriften)

[11] LOV-2009-03-06-11 Lov om tiltak mot hvitvasking og terrorfinansiering mv. (hvitvaskingsloven)

[12] LOV-2001-06-15-81 Lov om elektronisk signatur (esignaturloven).

[13] Kravspesifikasjon for PKI i offentlig sektor Versjon 2.


Commfides Norge AS

1. INTRODUCTION

1.1 Overview

Commfides Norge AS (Commfides) is a Qualified Trusted Service Provider (QTSP) as defined in Regulation

(EU) No 910/2014 [1]. A Trusted Service Provider (TSP) is an entity which provides one or more trust

services. A Qualified Trusted Service Provider (QTSP) is a trust service provider who provides one or more

qualified trust services and is granted the qualified status by the supervisory body. For Commfides the

supervisory body is the Norwegian Nkom. As a QTSP Commfides is the CA for the issuance of qualified

certificates (such as defined in articles 36 and 37 of the Regulation (EU) N° 910/2014 [1]) for qualified

electronic seal.

This document is the certificate policy (CP) and the certificate practice statement (CPS) for end-user

subscriber certificates signed by the subordinate CA certificate “CPN Enterprise SHA256 CLASS 3”. The

subordinate CA certificate is signed by the root certificate “CPN RootCA SHA256 Class 3”. This CP/CPS

covers in total six (9) different end-user certificates with different OIDs (see section “7.1.6 Certificate

Policy Object Identifier”). All are issued to legal persons (see section “3.2 Initial Identity Validation”)

They are divided in two categories the hard “CPN legal person NCP+” and the soft “CPN legal person NCP”

and “CPN legal person LCP”. In each group there are three (3) different certificates with different key

usage;

The EU qualified certificate with the key usage “Non-Repudiation (40)” used for authentication of

identity;

The certificate with the key usage “Digital signature (80)” that may, by the end-user, be used to

create an EU qualified seal (such as defined in article 3 (27) of the Regulation (EU) N° 910/2014 [1]

for the “CPN legal person NCP+”) and;

The certificate with the key usage “Key Encipherment, Data Encipherment, Key Agreement (38)”

used for encryption (see section “4.5 Key Pair and Certificate Usage” for details).

The end-user subscriber receives all these three certificates at the same time in the same device.

The hard and soft end-user certificates are separated in this CP/CPS respectively by “[CPN legal person

NCP+]”, “[CPN legal person NCP]” and “[CPN legal person LCP]” (see section “7.1.8 Policy Qualifiers Syntax

and Semantics”).

The “CPN legal person NCP+” certificates are delivered to the end-user on an encryption device and are

aligned with the NCP+ requirement in the ETSI EN 319 411-1 [3] and ETSI EN 319 411-2[4]. The same

encryption device is also a qualified seal creation device (QSCD), a device that is required to make an EU

qualified seal.

The overall responsible certificate authority (CA) for this CP and CPS is Commfides.


Commfides Norge AS

When referring to “The CA” or “The TSP” in this document it refers to the role as a CA or TSP that

Commfides have and are responsible for.

This document covers both the certificate policy (CP) and the belonging certification practice statement

(CPS) for the defined certificates. The CP is not separated from the CPS yet the document covers the

intentions with a CP and CPS which is defined like this;

A certificate policy (CP) states the applicability of a certificate and defines the security requirements that

are applied to the complete certificate lifecycle operated by the signing CA.

A certification practice statement (CPS) describes how the certificate policy is implemented in the context

of the operating policies, system architecture, physical security, and computing environment of the CA

organization.

The present CP/CPS is structured according to IETF RFC 3647 [5]. All sections of IETF RFC 3647 [5] are

used. Not relevant sections have a default value of “No stipulation”.

The TSP offers products and services for the complete e-ID lifecycle by the use of PKI certificates.

Within its scope, the TSP fulfils and acts accordingly to;

Regulation (EU) No 910/2014 [1], ETSI EN 319 401 [2], ETSI EN 319 411-1 [3] and ETSI EN 319 411-2 [4].

The qualified certificates issued by the TSP are aligned with ETSI EN 319 411-2 [4] and includes:

QCP-l and QCP-l-qscd,

Policy for EU qualified certificate issued to a legal person on a qscd

The non-qualified certificates are aligned with ETSI EN 319 411-1 [3] and includes

LCP, NCP and NCP+ policy for certificates issued to legal persons

The TSP acts in accordance with Norwegian laws. Particular relevant is law for e-signature

“Esignaturloven”, “Hvitvaskingsloven” and “Personopplysningsloven.

The Certificate-based Public Key Infrastructure governed by the TSP Certificate Policies (CP), which enables

the worldwide deployment and use of certificates by the TSP and its affiliates, and their respective

customers, subscribers, and relying parties is set up and maintained in an environment called Commfides

Trust Environment and is referred to as the CTE.

The CA may use other parties to provide parts of the certification service. However, the CA maintains the

overall responsibility and ensures that the policy requirements identified in the present document are

met.


Commfides Norge AS


Commfides Norge AS

Hierarchy

The table below shows the CA Hierarchy. This CP/CPS covers the certificates in the boxes “CPN legal

person NCP+”, “CPN legal person NCP” and the “CPN legal person LCP”


Commfides Norge AS

CA Hierarchy

Sub

ord

inat

e C

AEn

d-u

ser

sub

scri

ber

/su

bje

ctce

rtif

icat

esR

oo

t C

A

Certificates issued to natural persons Certificates issued to legal persons

CPN Person High SHA256 CLASS 3CPN Enterprise-Norwegian SHA256 CA

CLASS 3

CPN RootCA SHA256 Class 3

CPN natural person central NCP+

QCP-n-qscd (non-repudiation)CP OID:2.16.578.1.29.12.10.X.XETSI Policy OID: 0.4.0.194112.1.2

NCP+ (digital signature)CP OID:2.16.578.1.29.12.11.X.XETSI Policy OID: 0.4.0.2042.1.2

NCP+ (encryption) CP OID:2.16.578.1.29.12.12.X.XETSI Policy OID: 0.4.0.2042.1.2

CPN legal person NCP+

NCP+ (non-repudiation) CP OID:2.16.578.1.29.13.10.X.XETSI Policy OID: 0.4.0.2042.1.2

QCP-l-qscd (digital signature)CP OID:2.16.578.1.29.13.11.X.XETSI Policy OID: 0.4.0.194112.1.3

NCP+ (encryption)CP OID:2.16.578.1.29.13.12.X.XETSI Policy OID: 0.4.0.2042.1.2

CPN natural employee central NCP+


NCP+ (digital signature) CP OID:2.16.578.1.29.12.21.X.XETSI Policy OID: 0.4.0.2042.1.2

NCP+ (encryption) CP OID:2.16.578.1.29.12.22.X.XETSI Policy OID: 0.4.0.2042.1.2

CPN legal person NCP

NCP (non-repudiation)CP OID:2.16.578.1.29.13.20.X.XETSI Policy OID: 0.4.0.2042.1.1

QCP-l (digital signature)CP OID:2.16.578.1.29.13.21.X.XETSI Policy OID:0.4.0.194112.1.1

NCP (encryption)CP OID:2.16.578.1.29.13.22.X.XETSI Policy OID: 0.4.0.2042.1.1

SigningSigning

Signing

CPN natural employee distributed NCP+


NCP+ (digital signature) CP OID:2.16.578.1.29.12.31.X.XETSI Policy OID: 0.4.0.2042.1.2

NCP (encryption) CP OID:2.16.578.1.29.12.32.X.XETSI Policy OID: 0.4.0.2042.1.1

Signing

CPN legal person LCP

LCP (non-repudiation)CP OID:2.16.578.1.29.13.30.X.XETSI Policy OID: 0.4.0.2042.1.3

LCP (digital signature)CP OID:2.16.578.1.29.13.31.X.XETSI Policy OID:0.4.0.2042.1.3

LCP (encryption)CP OID:2.16.578.1.29.13.32.X.XETSI Policy OID: 0.4.0.2042.1.3


Commfides Norge AS

1.2 Document Name and Identification

This CP/CPS covers end-user certificates that are signed by the subordinate CA certificate “CPN Enterprise

SHA256 CLASS 3”. The subordinate CA certificate is signed by the root CA certificate “CPN RootCA SHA256

Class 3”. Certificate policy object identifiers are used in accordance with section “7.1.6 Certificate Policy

Object Identifier”.


Commfides Norge AS

1.3 PKI Participants

The PKI under this CP/CPS applies to and holds the following roles.

CA

The Certificate Authority trusted by the users of the certification services to create and assign

certificates.

RA

Registration Authorities (RA) that is responsible for identification and authentication of subjects

and subscriber of the certificates.

Subcontractors

Party providing services on behalf of the TSP/The CA.

Subscribers

Legal or natural person bound by agreement with a trust service provider to any subscriber

obligations.

Subject

Entity identified in a certificate as the holder of the private key associated with the public key

given in the certificate.

Relying parties

A natural or legal person that relies upon an electronic identification or a trust service.

1.3.1 Certification Authorities

The authority trusted by the users of the certification services (i.e. subscribers as well as relying parties)

to create and assign certificates is called the CA.

Commfides Norge AS operates as the CA and the TSP for all certificates issued within this Certificate

Policy and thereby fulfils all CA obligations.

The TSP has the overall responsibility for the provision of the certification services. The TSP offers the

following services;

Registration service,

Certificate generation service,

Dissemination service,

Revocation management service,

Revocation status service,


Commfides Norge AS

Subject device provision service

The subject device provision service is only relevant when secure cryptographic device is used to holds

the user's private key.

The TSP provide customer support service, to be reached at [email protected] or by phone.

The CA is identified in the certificate as the issuer and its private key is used to sign certificates.

Commfides Norge AS is the CA that is identified as the issuer of the certificates issued within this

certificate policy.

The TSP makes use of other parties to provide parts of the certification service. However, the TSP always

maintains overall responsibility and ensures that the policy requirements identified in the present

document are met.

The TSP may sub-contract the entire component services, including the certificate generation service (If

stated in this CP/CPS) However the key used to sign the certificates are identified as belonging to the CA,

and the CA maintains overall responsibility for meeting the requirements defined in the present

document. (See section “1.3.5 Other Participants” for sub-contracted services)

A CA is a type of Trust Service Provider (TSP), as defined in the Regulation (EU) No 910/2014 [1], and also

a form of certification service provider which issues public key certificates.

The present CP/CPS identifies the obligations of all external organizations supporting the TSP services

including the applicable policies and practices. See section “1.3.5 Other Participants”

Section “1.1 Overview” includes a hierarchy of subordinate CAs up to a root CA certificate; the TSP is

responsible for ensuring the subordinate-CAs complies with the applicable policy requirements.

Regulation (EU) No 910/2014 [1] addresses liability of trust service providers. In particular, the TSP

identified as the qualified TSP issuing EU qualified certificates in the trusted list of qualified services,

maintains overall responsibility for meeting liability for the issuing of certificates as required in Regulation

(EU) N° 910/2014 [1].

The root “CPN RootCA SHA256 Class 3” certificate is signing subordinate CA certificates as indicated in

section “7.1.6 Certificate Policy Object Identifier”

1.3.2 Registration Authorities

Registration Authorities (RA) is the entity responsible for identification and authentication of subjects of

certificates. The TSP operates the registration authorities (RA) and the accompanying registration service

under this certificate policy, which has not been subcontracted.

mailto:[email protected]


Commfides Norge AS

The RA does:

Receive certificate applications from subscribers and subject, both for initial- and renewal

application.

Verify all information submitted by subscribers and subjects, both for initial- and renewal

applications and if the verifications are successful, submit requests to the CA for issuance of a

certificate.

In order to submit request to the CA for issuance of a certificate, the RA must be ensured that

identification and authentication is according to section “3 Identification and authentication” in

this policy.

Receive and verify all requests from subscribers and subjects for revocation of certificates, and if

verifications of revocation requests are successful, submit requests to the CA for revocation of

their certificates.

Always notify the subscribers and subjects that their certificate has been issued.

Always notify subscribers and subjects that their certificate has been revoked, suspended or will

expire soon.

The TSP does use RA operators to perform parts of or all the tasks above. Listing of all approved RA

operators and their tasks is to be found in the internal TSP document “CN-GDOC-20_Organization

overview”.

1.3.3 Subscribers (End Entities)

Subscriber and subject

The subject is a: legal person (that can be an Organization or a unit or a department identified in

association with an Organization). The subscriber is the same legal entity as the subject. Responsibilities

of the subscriber and of the subject are addressed in below in this section.

A subscriber is a legal person bound by agreement with a trust service provider to any subscriber

obligations. The subscriber shall fulfil all obligations of the subscriber agreement. The subject shall fulfil all

obligations of the subject agreement. If the subscriber and subject are separate entities, the subscriber

shall make the subject aware of those obligations applicable to the subject.

The subscriber shall:

a) Submit accurate and complete information to the TSP in accordance with the requirements in the

certification practice statement.

b) Maintain the correct information about the subscriber and subject, and notify the TSP of any

changes to this information.

c) Notify the TSP if any information in the Certificate is incorrect.

d) Request the certificate to be revoked when a valid revocation reason exists (see “4.9.1

Circumstances for Revocation”).


Commfides Norge AS

e) In the case of being informed that the CA has been compromised, ensure that the private key is

no longer used by the subject.

f) Inform the TSP if an authorized subscriber representative no longer is authorized to represent the

subscriber.

g) Exercise reasonable care to avoid unauthorized use of the subjects’ private keys.

Particularly keep the activation data (PIN) secret

h) Ensure that restrictions on the subject’s private key and the certificate are kept at all times.

i) Ensure that the use of the subject private keys is immediately and permanently discontinued in

case of private key compromise. For instance if control of the subject private keys are lost.

j) Cease the use of the private keys at the end of the key usage periods (use for key decipherment is

accepted).

k) Ensure the key pair is only used in accordance with any limitations notified to the subscriber and

the subject if the subject is a natural or legal person. Limitation is notified in each certificate

associated PDS (see also section “9.17 Other Provisions” under “Terms and Condition”);

l) Use and maintain the subject's private key under the subject's sole control.

m) Notify the TSP without any reasonable delay, if any of the following occur up to the end of the

validity period indicated in the certificate: i) the subject's private key has been lost, stolen,

potentially compromised or; ii) control over the subject's private key has been lost due to

compromise of activation data (e.g. PIN code) or other reasons.

[CPN legal person NCP+]

n) Use the subject's private key(s) for cryptographic functions within the secure cryptographic

device. Digital seal shall only be created by the QSCD device.

[CPN legal person NCP+] [CPN legal person NCP] and [CPN legal person LCP]

o) Ensure that use of the certificate is under subscriber control by recording all entities that use and

have access to the private keys, included processes, systems and individuals.

The subject shall:

The subject shall act according to the following points; a), d), e) g), h), i) , j), k) l) m) n)

(If the subscriber is the same entity as the subject, then all the subscriber obligation applies to the subject

as well).

1.3.4 Relying Parties

A relying party is a natural or legal person that relies upon an electronic identification or a trust service. A

relying party is responsible for deciding whether or not to rely on certificates issued according to this

certificate policy and shall for these certificates:

Relying parties must independently assess the appropriateness of the use of a certificate for any given

purpose and determine that the certificate will, in fact, be used for an appropriate purpose. The TSP is


Commfides Norge AS

not responsible for assessing the appropriateness of the use of a certificate. (See section “9.9

Indemnities” for relying parties)

Relying parties must utilize the appropriate software and/or hardware to perform digital signature

verification or other cryptographic operations they wish to perform, as a condition of relying on

certificates in connection with each such operation. Such operations include identifying a certificate chain

and verifying the digital signatures on all certificates in the certificate chain. Under these agreements,

relying parties must not rely on a certificate unless these verification procedures are successful.

Relying parties is required to check the status of a certificate on which they wish to rely, as well as all the

certificates in its certificate chain. If any of the certificates in the certificate chain have been revoked, the

relying party must not rely on the end-user subscriber certificate or other revoked certificate in the

certificate chain.

Relying party agreements state that assent to their terms is a condition of using or otherwise relying on

certificates. Relying parties that are also subscribers agree to be bound by relying party terms under this

section, disclaimers of warranty, and limitations of liability when they agree to a subscriber agreement.

If all of the checks described above are successful, the relying party is entitled to rely on the certificate,

provided that reliance upon the Certificate is reasonable under the circumstances. If the circumstances

indicate a need for additional assurances, the relying party must obtain such assurances for such reliance

to be deemed reasonable.

Relying party agreements state that relying parties must not monitor, interfere with, or reverse engineer

the technical implementation of the TSP’s infrastructure, except upon prior written approval from the

TSP, and shall not otherwise intentionally compromise the security of the TSP.

Check current and updated CRL if the certificate has been revoked.

When deciding whether to have confidence in a signature or seal take into account all the information in

the certificate, its associated certificate policy and best practice.

If it is not possible to verify all of the points above then the relying party should not trust the certificate.


Commfides Norge AS

1.3.5 Other Participants

The TSP allows subcontractor providing services on behalf of the TSP. Defining subcontractor here as a

party providing certification services on behalf of the TSP. A prerequisite is that they are capable of

operate in conformance with the TSP’s certificate policy. Conformance assessments are required and are

defined and handled by the TSP. The TSP’s internal information security policy set requirements for

subcontractors/3rd party services. The TSP’s internal document “Monitoring and Review of 3rd Party

Services” gives a list of all subcontractors performing certification services, what services they perform

and which certificate profile (with belonging OIDs) they have a role in.

Relevant subcontractors are:

Delivery and identification services and;

Part of the registration service and subject device provision service may be subcontracted to the

Norwegian postal service using their PUM services for secure distribution of Activation Data (PIN) and

Hardware token containing the private key.

Suppliers of card and certificate managements systems

1.4 Certificate usage

See section “4.5 Key Pair and Certificate Usage”

1.4.1 Appropriate Certificate Uses

See CPS section “4.5 Key Pair and Certificate Usage”

1.4.2 Prohibited Certificate Uses

See CPS section “4.5 Key Pair and Certificate Usage”


Commfides Norge AS

1.5 Policy Administration

The Commfides Certificate Advisory Board (Commfides CAB) is responsible for all aspects of the CTE, CP

and the CPS. Inquiries to the TSP should be addressed as follows:

Commfides Norge AS,

Fornebuveien 1,

PO-box 405

N-1327 Lysaker Norway

Attn: Commfides Practices Development – CPS

Telephone: +47 21 55 62 60

Email: [email protected]

1.5.1 Organization Administering the Document

The Commfides Certificate Advisory Board (CAB) is responsible for all aspects of the CTE, CP and the CPS.

1.5.2 Contact Person

Contact person is the Security Officer in The Commfides Certificate Advisory Board (CAB) in Commfides

Norge AS.

Contact point is through Commfides Norge AS at:[email protected]

1.5.3 Person Determining CPS Suitability for the Policy

The person determining CPS suitability for the policy is the Security Officer in The Commfides Certificate

Advisory Board (CAB) in Commfides Norge AS

Contact point is through Commfides Norge AS at:

[email protected]

1.5.4 CPS approval procedures

The Commfides Certificate Advisory Board (CAB) is responsible for the CP and CPS. All changes must be

approved by the CAB. The Commfides CAB has the overall responsibility to implement and maintain the

practices stated in this CPS.





Commfides Norge AS

1.6 Definitions and Acronyms

CP/CPS

Term Definition

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 NOTE 2: This is a specific type of trust service policy as specified in ETSI EN 319 401

Certification Practice Statement (CPS)

Statement of the practices which a Certification Authority employs in issuing managing, revoking, and renewing or re-keying certificates. NOTE 2: This is a specific type of Trust Service practice statement as specified in ETSI EN 319 401

Trust service policy Set of rules that indicate the applicability of a trust service to a particular community and/or class of application with common security requirements. NOTE: See clause 6 for further information on TSP policy.

Trust service practice statement

Statement of the practices that a TSP employs in providing a trust service NOTE: See clause 6.2 for further information on practice statement.

PKI - Participants

Term Definition

Administrator Administrator is an entity authorized by a subscriber’s representor to request end-user subscriber certificates on behalf of the subscriber.

Auditor Person who assesses conformity to requirements as specified in given requirement documents

Body governed by public law

A body defined in point (4) of Article 2(1) of Directive 2014/24/EU of the European Parliament and of the Council ( 1 )

Certification Authority (CA)

Authority trusted by one or more users to create and assign certificates NOTE 1: A CA can be: 1) a trust service provider that creates and assigns public key certificates; or 2) a technical certificate generation service that is used by a certification service provider that creates and assign public key certificates.

Commfides Certificate Advisory Board (CAB)

Certificate Advisory Board is a part of Change Advisory Board that is responsible for changes made to the CP/CPS. All changes must be approved by the CAB

Conformity assessment body

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

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

CTE Participant An individual, organization or other entity with participation in the CTE including: Commfides, RAs, LRAs, Customers, subscribers, Subcontractors and relying parties.

Qualified trust service provider

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


Commfides Norge AS

Registration Authority (RA)

Entity that is responsible for identification and authentication of subjects of certificates mainly. NOTE 1: An RA can assist in the certificate application process or revocation process or both. NOTE 2: See IETF RFC 3647

Registration officer Person responsible for verifying information that is necessary for certificate issuance and approval of certification requests.

Relying party A natural or legal person that relies upon an electronic identification or a trust service. Relying parties include parties verifying a digital signature using a public key certificate.

Revocation officer Person responsible for operating certificate status changes

Security Officers Overall responsibility for administering the implementation of the security practices.

Signatory A natural person who creates an electronic signature

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

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

Subscriber’s representor

If the subject and subscriber for a certificate is not the same entity, the subscriber shall be represented by a natural person, called the subscriber’s representor. Given the subscriber is a legal person (and not a natural person).

Subcontractor Party providing services on behalf of the CA.

System Administrators

Authorized to install, configure and maintain the TSP trustworthy systems for service management, included recovery of the system.

System Auditors Authorized to view archives and audit logs of the TSP trustworthy systems.

System Operators Responsible for operating the TSP trustworthy systems on a day-to-day basis. Authorized to perform system backup.

Trust anchor: Entity that is trusted by a relying party and used for validating certificates in certification paths. NOTE 1: See ISO/IEC 9594-8/Recommendation ITU-T X.509 [6]. NOTE 2: A Trust Anchor can also be a Root CA. NOTE 3: Examples of trust anchors are as in a trusted List or a list of trusted CA certificates distributed by an application software provider.

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

Trusted Persons Persons, including employees, subcontractors or consultants of entities within the CTE who are responsible for managing infrastructure, an entities services, facilities and/or its practices.

Trusted Position A position within the CTE that must be held by a Trusted Person.


Commfides Norge AS

Other

Term Definition

Activation Data Private data, other than keys, that are required to access cryptographic modules (i.e., unlock private keys for signing or decryption events).

Advanced electronic seal

An electronic seal, which meets the requirements set out in Article 36 in Regulation (EU) No 910/2014 [1]

Advanced electronic signature

An electronic signature which meets the requirements set out in Article 26 Regulation (EU) No 910/2014 [1]

Attribute Information bound to an entity that specifies a characteristic of an entity, such as a group membership or a role or other information associated with that entity.

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

Certificate Operational Period

The period starting from the date and time a Certificate is issued and ending on the earlier date and time a Certificate expires or is otherwise earlier revoked.

Certificate Revocation List (CRL)

Signed list indicating a set of certificates that are no longer considered valid by the certificate issuer. NOTE 1: Within the scope of the present document the set of certificates is related to end-user certificates. NOTE 2: See ISO/IEC 9594-8/Recommendation ITU-T X.509 [6].

Certification Authority Revocation List (CARL)

Revocation list containing a list of CA-certificates issued to certification authorities that are no longer considered valid by the certificate issuer NOTE: See ISO/IEC 9594-8/Recommendation ITU-T X.509 [6].

Class A specified level of assurance

Commfides Professional Network (CPN)

The Commfides Hierarchy from root and trusting certificates

Commfides Trust Environment (CTE)

The Certificate-based Public Key Infrastructure governed by the Commfides Certificate Policies, which enables the worldwide deployment and use of certificates by Commfides and its Affiliates, and their respective Customers, subscribers, and relying parties.

Commfides UNID Service

Commfides have developed an UNID service in accordance with «SEID leveranse nummer 2 – Grensesnitt for tilgang til oppslagstjenester».

Compromise Disclosure of information to unauthorized persons, or a violation of the security policy of a system in which unauthorized intentional or unintentional disclosure, modification, destruction, or loss of an object may have occurred.

Coordinated Universal Time (UTC)

As defined in ETSI EN 319 401 [2].

Digital signature: Data appended to, or a cryptographic transformation of a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery e.g. by the recipient. NOTE: See ISO/IEC 7498-2/Recommendation ITU-T X.800

Electronic identification

The process of using person identification data in electronic form uniquely representing either a natural or legal person, or a natural person representing a legal person

Electronic identification means

A material and/or immaterial unit containing person identification data and which is used for authentication for an online service

Electronic identification scheme

A system for electronic identification under which electronic identification means are issued to natural or legal persons, or natural persons representing legal persons


Commfides Norge AS

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

Electronic seal creation data

Unique data, which is used by the creator of the electronic seal to create an electronic seal

Electronic seal creation device

Configured software or hardware used to create an electronic seal

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

Electronic signature creation data

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

Electronic signature creation device

Configured software or hardware used to create an electronic signature

High security zone: Specific physical location of the security zone (see ETSI EN 319 401 [2], clause 7.8) where the Root CA key is held.

Key Escrow A deposit of the private key of a subscriber and other pertinent information pursuant to an escrow agreement or similar contract binding upon the subscriber, the terms of which require one or more subcontractor to hold the subscriber's private key for the benefit of the subscriber, an employer, or other party, upon provisions set forth in the agreement.

Local Registration Authority (LRA)

Carry out registration tasks on behalf of and is under the authority of a RA.

Object Identifier (OID) A specialized formatted number that is registered with an internationally recognized standards organization. The unique alphanumeric/numeric identifier registered under the ISO registration standard to reference a specific object or object class.

Person identification data

A set of data enabling the identity of a natural or legal person, or a natural person representing a legal person to be established

Private Key (1) The key of a signature key pair used to create a digital signature. (2) The key of an encryption key pair that is used to decrypt confidential information. In both cases, this key must be kept secret.

Product Hardware or software, or relevant components of hardware or software, which are intended to be used for the provision of trust services

Public Key (1) The key of a signature key pair used to validate a digital signature. (2) The key of an encryption key pair that is used to encrypt confidential information. In both cases, this key is made publicly available normally in the form of a digital certificate.

Public Key Infrastructure (PKI)

A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates.

Qualified electronic seal

An advanced electronic seal, which is created by a qualified electronic seal creation device, and that is based on a qualified certificate for electronic seal

Qualified electronic seal creation device

An electronic seal creation device that meets mutatis mutandis the requirements laid down in Annex II

Qualified electronic signature

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

Qualified electronic signature creation device

An electronic signature creation device that meets the requirements laid down in Annex II

Qualified trust service A trust service that meets the applicable requirements laid down in this Regulation

Relying party agreement

An agreement used by a CA to set out the terms and conditions for acting as a relying party


Commfides Norge AS

Root CA Certification authority which is at the highest level within TSP's domain and which is used to sign subordinate CA(s). NOTE 1: A Root CA certificate is generally self-signed but the Root-CA can also be certified by a (Root) CA from another domain (e.g. cross-certification, Root-Signed in the context of a root-signing program, etc.). NOTE 2: A Root CA can be used as the Trust Anchor for many applications (e.g. browsers) but nothing prevents the TSP to present subordinate CAs for this purpose, according to the business context.

Secure cryptographic device

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

Secure zone Area (physical or logical) protected by physical and logical controls that appropriately protect the confidentiality, integrity, and availability of the systems used by the TSP.

Sub domain The portion of the CTE under the control of a CTE Member and including all entities subordinate to it.

Subordinate CA Certification authority who’s Certificate is signed by the Root CA, or another Subordinate CA. NOTE: A subordinate CA normally either issues end-user certificates or other subordinate CA certificates.

Subscriber agreement An agreement used by a CA or RA setting forth the terms and conditions to be a Subscriber.

Superior CA In a hierarchical PKI, a CA who has certified the certificate signature key of another CA, and who constrains the activities of that CA. (See subordinate CA).

Trust service An electronic service normally provided for remuneration which consists of: (a) the creation, verification, and validation of electronic signatures, electronic seals or electronic time stamps, electronic registered delivery services and certificates related to those services, or (b) the creation, verification and validation of certificates for website authentication or (c) the preservation of electronic signatures, seals or certificates related to those services

Trust service token Physical or binary (logical) object generated or issued as a result of the use of a trust service. NOTE: Examples of trust service tokens are: certificates, CRLs, time-stamp tokens, OCSP responses.

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

Validation data Data that is used to validate an electronic signature or an electronic seal

Certificates

Term Definition

Certificate Public key of a user, together with some other information, rendered un-forgeable by encipherment with the private key of the certification authority which issued it. NOTE 1: The term certificate is used for public key certificate within the present document. NOTE 2: See ISO/IEC 9594-8/Recommendation ITU-T X.509 [6].

Certificate for electronic seal

An electronic attestation that links electronic seal validation data to a legal person and confirms the name of that person

Certificate for electronic signature

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


Commfides Norge AS

Cross Certificate: Certificate that is used to establish a trust relationship between two certification authorities

Publicly-Trusted Certificate (PTC)

Certificate that is trusted by virtue of the fact that its corresponding Root Certificate is distributed as a trust anchor in widely-available application software.

Qualified certificate for electronic seal

A certificate for an electronic seal, that is issued by a qualified trust service provider and meets the requirements laid down in Annex III

Qualified certificate for electronic signature

A certificate for electronic signatures, that is issued by a qualified trust service provider and meets the requirements laid down in Annex I

Qualified certificate for website authentication

A certificate for website authentication, which is issued by a qualified trust service provider and meets the requirements laid down in Annex IV

End-user subscriber certificates

Certificates issued to subscribers/subjects. (CA root certificate and subordinate CA certificates is not part of this term).


Commfides Norge AS

1.6.1 Acronyms

CA Certification Authority

CAB Certificate Advisory Board

CARL Certificate Authority Revocation List

Commfides Commfides Norge AS

CP Certificate Policy

CPS Certification Practice Statement

CRL Certificate Revocation List

CTE Commfides Trusted Environment

ISMS Information Security Management System

LDAP Lightweight Directory Access Protocol

LRA Local Registration Authorities

OCSP Online Certificate Status Protocol

OID Object Identifier

PIN Personal Identification Number

PKI Public Key Infrastructure

RA Registration Authority

RSA Rivest-Shamir-Adleman

SOA Statement of Applicability

SSL Secure Sockets Layer

TLS Transport Layer Security

TSP Trusted Service Provider

QSCD May indicate “Qualified Signature Creation Device” and/ or “Qualified Seal Creation Device”


Commfides Norge AS

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1 Repositories

The TSP is responsible for the repository function for its CA.

The TSP publishes certain CA information in the repository section of the TSP’s web site at

http://crl1.commfides.com/Commfides-CP-and-CPS-for-Certificates-and-EU-Qualified-Certificates-Legal-

Person-Central.pdf

The TSP publishes the CPS and subscriber agreements in the repository section of Commfides’ web site.

2.2 Publication of Certification Information

The TSP makes certificates available to subscribers, subjects and relying parties. In particular:

Dissemination

a) Upon generation, the complete and accurate certificates are available to the subscriber or subject for

whom the certificate is being issued.

b) Certificates are available for retrieval in only those cases for which the subject's consent has been

obtained. If the subject is a device or system, the consent of the natural or legal person responsible for

the operating of the device or system are obtained, instead of the subject.

c) The TSP make available to relying parties the terms and conditions regarding the use of the certificate

(see clause “9.17 Other Provisions” under “Terms and Condition”).

d) The applicable terms and conditions are readily identifiable for a given certificate.

e) The information identified in b) and c) above are available 24 hours per day, 7 days per week. Upon

system failure, service or other factors which are not under the control of the TSP, the TSP apply best

endeavours to ensure that this information service is not unavailable for longer than a maximum period

of time as denoted in the CPS, see CPS section “4.10 Certificate Status Services”.

f) The information identified in c) above are publicly and internationally available.

Security documents considered confidential by the TSP are not disclosed to the public. Confidential

security documents include the documents identified in section “9.4.2 Information Treated as Private” as

documents that are not available to the public.

The CPS is published in electronic form within the TSP’s repository at

http://crl1.commfides.com/Commfides-CP-and-CPS-for-Certificates-and-EU-Qualified-Certificates-Legal-

Person-Central.pdf and are be public available 24 hours per day, 7 days per week.

http://crl1.commfides.com/Commfides-CP-and-CPS-for-Certificates-and-EU-Qualified-Certificates-Legal-Person-Central.pdf





Commfides Norge AS

The CPS is available in the TSP’s repository in pdf.

2.3 Time or Frequency of Publication

Updates to the CPS are published as the changes are taken into effect. (See CPS section “9.12

Amendments” for more details regarding changes to the CP/CPS)

Updates to subscriber agreements are published as necessary.

Certificates are published upon issuance.

Certificate status information is published in accordance with section “4.10 Certificate Status

Services”

2.4 Access Controls on Repositories

Information published in the repository portion of the TSP’s web site is publicly-accessible information.

Read only access to such information is unrestricted. The TSP requires persons to agree to a relying party

agreement or CRL usage agreement as a condition to accessing certificates, certificate status information,

or CRLs. The TSP has implemented logical and physical security measures to prevent unauthorized

persons from adding, deleting, or modifying repository entries.


Commfides Norge AS

3. IDENTIFICATION AND AUTHENTICATION

3.1 Naming

3.1.1 Types of Names

The CA certificates contain X.501 distinguished names in the issuer and subject fields. Issuer distinguished

names consist of the components specified in the table below.

Attribute Value

Country (C) The CAs country or origin.

Organization (O)

Indicates the controlling organization of the CA

Organizational Unit (OU)

The CA certificates contain several OU attributes which specify the CA’s position in the CTE hierarchy and type of certificate issued.

State or Province (S)

Indicates the CAs state or province.

Locality (L) Indicates the CAs city.

Common Name (CN)

This attribute is the common name of the CA.

The subscriber certificates contain an X.501 distinguished name in the subject name field and consist of

the components specified in Table 5 below.

Attribute Value

Country (C) Indicates the subscriber’s Country.

Organization (O) Subscriber’s organizational or company name for Subscriber’s personal certificate or not used.

Organizational Unit (OU)

The subscriber certificates may contain multiple OU attributes. Such attributes may contain one or more of the following: subscriber organizational unit. An indication of which CA issued the Certificates. “Authenticated by Commfides” or other entity in certificates whose applications were authenticated by Commfides or other entity.

Organization Identifier

NTRNO-<Business number as stated in Brønnøysundsregistrene or other applicable identification practices>

State or Province (S)

Indicates the subscriber’s state or province or not used.

Locality (L) Indicates the subscriber’s locality or not used.


Commfides Norge AS

Common Name (CN)*

This attribute includes the name of the individual or device (hostname in the case of server Certificates).

*Common Name (CN)

Component of the subject distinguished name of subscriber certificates is authenticated.

Subject name e.g. subscriber name, system name, application name, or domain name owned by

the company can be included.

3.1.2 Need for Names to be Meaningful

CA Certificates contain names with commonly understood semantics permitting the determination of the

identity of the CA that is the subject of the certificate.

For use of email address, the address must be meaningful

For subscriber certificates the full name and legal status of the subscriber as defined in the national

business register or equivalent for Legal Entities must be used and it must be able to identify both

certificate applicants and subject sponsors as authorized subscriber representatives.

3.1.3 Anonymity or Pseudonymity of Subscribers

Anonymity or Pseudonymity of subscribers is not allowed.

3.1.4 Rules for Interpreting Various Name Forms

No stipulation.

3.1.5 Uniqueness of Names

Only CA certificates names are unique.

3.1.6 Recognition, Authentication, and Role of Trademarks

For role of Trademark see CPS section “9.5 Intellectual Property Rights”.


Commfides Norge AS

3.2 Initial Identity Validation

The TSP verifies the identity of the subscriber and subject and check that certificate requests are

accurate, authorized and complete according to the collected evidence or attestation of identity. The TSP

may authorize a subcontractor (as defined in section “1.3.5 Other Participants”) to perform parts of or

the entire identification and delivery process. These entities are as the TSP is, obligated to perform the

identity validation of the entities and roles as described in this section.

The TSP ensures within the certificate generation- and distribution process that only the subscriber have

the simultaneously control of both the private key and its associated activation codes (PIN).

The certificate and the associated activation code (PIN) are delivered separately.

The following assumption applies for this certificate profile:

There is a legal person identified in the certificate;

The subject is a legal person or other organizational entity identified in association with a legal person.

The subscriber will be the legal person it selves or the legal person identified in association with the

organizational entity being the subject. There shall be an authorized natural person representing the

subject and subscriber to request for the certificate, called the subscriber’s representor.

The subscriber’s representor must be represented in the “Brønnøysundsregistrene” or equivalent

international business register in association with the legal person (subscriber). If a country does not

have a business register, an approval by a notarius publicus may be accepted.

Both the subscriber’s representor and its role are verified by the TSP. (See point 3 and 6 below).

The subscriber’s representor may authorize another natural person as an administrator, having the right

to request for certificates to the subject/subscriber. The subscriber’s representor/administrator shall

authorize a natural person to be the receiver of the certificate; it may be the subscriber’s representor him

or her selves.

The following entities and relations are being validated, authenticated and provided records of by the TSP

prior to deliverance of the certificate and activation codes;

Entities;

1) The subject (a legal person)

2) The subscriber (a legal person)

3) The subscriber’s representor (a natural person)

4) The administrator (a natural person)

5) The receiver of the certificate (a natural person)

Relations;

6) The legal right for the subscriber’s representor to represent the subject/subscriber

7) The authorization for being an administrator (only applicable if an administrator is registered)


Commfides Norge AS

For these entities and relation the TSP provides, records evidence and authenticate the following;

1) The subject (a legal person)

The TSP authenticate

a) That the full name and organization number of the subscriber is identified in the certificate

application;

b) That the subscriber is registered and has a valid status in the national Brønnøysundregistrene or

other applicable identification practices;

c) The consistency between the name and organization number from the certificate application

and the national Brønnøysundregistrene or other applicable identification practices; and

d) The physical address, email or other means, which give information on how the subscriber can

be contacted.

2) The subscriber - legal person

Same validation as for the “1) The subject (a legal person)” above.

3) The subscriber’s representor (a natural person)

The TSP authenticate:

a) That the subscriber’s representor is identified in the certificate application with a copy of his or

hers nationally recognized identity paper.

b) The validity of the identity document.

c) Consistency between the mandatory signature in the certificate application by the subscriber’s

representor and the mandatory signature by the subscriber’s representor in the identity

document.

e) Consistency between the mandatory full name and social security number of the subscriber’s

representor in the certificate application and the full name and social security number in the

National Registry of Persons (DSF) or equivalent International registry.

f) The validity of the subscriber’s representor status in the National Registry of Persons (DSF) or

equivalent International registry must be valid.

4) The Administrator (a natural person)

Same validation as “3) The subscriber’s representor (a natural person)”above

5) The receiver of the certificate (a natural person):



Commfides Norge AS

a) That the full name and social security number of the subject is identified in the certificate

application;

[CPN legal person NCP+] and [CPN legal person NCP]

b) That the person claim to be the receiver of the certificate is the same person identified as the

receiver in the certificate application. In order to do so, the receivers identity is checked either

directly, by physical presence and witnessed in person by the TSP, or is checked indirectly using

means which provides equivalent assurance to physical presence; and


c) During this presence, the receiver is requested to identify himself/herself by presenting a

nationally recognized Identity document to the TSP.

The following elements are then authenticated:

1) The validity of the identity document.

2) The consistency between the picture on the identity document and the present person

3) The consistency between the mandatory signature for receiving the certificate and the

mandatory signature on the identity document

4) The consistency between the full name (including surname, middle and given names) and social

security number in the identity document and the authorized receiver of the certificate.

[CPN legal person LCP]

d) That the person claim to be the receiver of the certificate is the same person identified as the

receiver in the certificate application. In order to do so the TSP is sending the certificates to the

receiver by encrypted e-mail and code to validated cell phone. The receiver signs a delivery form,

and confirms that certificates has been received and provide photo copy of identification. If found

authentic the PIN is sent encrypted to the receiver.


e) The receiver identify himself/herself by sending copy of a nationally recognized Identity

document to the TSP.

The following elements are then authenticated:

1) The validity of the identity document.

2) The consistency between the picture on the identity document and the present person

3) The consistency between the mandatory signature for receiving the certificate and the

mandatory signature on the identity document

4) The consistency between the full name (including surname, middle and given names) and social


Commfides Norge AS

security number in the identity document and the authorized receiver of the certificate.

6) The legal right for the subscriber’s representor to represent the subject/subscriber

The natural person identified as subscriber’s representor in the certificate application for the

subscriber shall be listed at the national Brønnøysundregistrene or other applicable identification

practices by its name and having a specific role for the subscriber. The roles allowed for

representation are listed in internal Policy documentation at the TSP.

7) The authorization for being an administrator (only applicable if an administrator is registered)


The authorization by the subscriber’s representor to an identified administrator in the certificate

application to request certificates on behalf of the subscriber. A valid authorization gives the

administrator the right to order certificates on behalf of the subscriber without the subscriber’s

representor participation. The TSP doesn’t accept the administrators to delegate their role unless

it is agreed upon and accepted by the subscriber’s representor.


Commfides Norge AS

3.2.1 Method to Prove Possession of Private Key

Method to prove possession of private key is not applicable as the key pair of the certificates is generated

by and under control of the TSP.

3.2.2 Authentication of Organization Identity

See CPS section “3.2 Initial Identity Validation” above. For Organization Identity one uses the concept

legal person.

3.2.3 Authentication of Individual Identity

See CPS section “3.2 Initial Identity Validation” above. For Individual Identity one uses the concept natural

person.

3.2.4 Non-Verified Subscriber Information

Not applicable.

3.2.5 Validation of Authority

See CPS section “3.2 Initial Identity Validation” above, in particular the phase relations as used for all

certificate types, where requirements for validation of authority is described for each required element.

3.2.6 Criteria for Interoperation

Not applicable.


Commfides Norge AS

3.3 Identification and Authentication for Re-Key Requests

The TSP doesn’t offer certificate re-key.

3.3.1 Identification and Authentication for Routine Re-Key


3.3.2 Identification and Authentication for Re-Key after Revocation


3.4 Identification and Authentication for Revocation Request

The Circumstances for revocation is found in section “4.9.1 Circumstances for Revocation”. Who can

Request Revocation is found in section “4.9.2 Who can Request Revocation” and procedure for

Revocation Request is found in section “4.9.3 Procedure for Revocation Request”. The TSP shall take into

account the potential negative impact of misuse of a certificate is larger than the negative impact if a

certificate is mistakenly revoked.

The TSP does revoke subscriber certificates upon request;

a) If not the TSP find it quite unlikely that the request for revocation is valid.

b) If not the request is so insufficient that the TSP is not able to identify which subscriber certificate

that is request to be revoked.

If the request for revocation is valid due to a set of minimum requirements the requested certificate shall

be revoked. See CP/CPS section “4.9.3 Procedure for Revocation Request”.


Commfides Norge AS

4. CERTIFICATE LIFE-CYCLE OPERATIONAL

REQUIREMENTS

4.1 Certificate Application

The certificate application for certificates are securely checked by trusted personnel in trusted roles, by

defined written procedures for registration (see section “4.2 Certificate Application Processing” below)

and according to the TSP certification services procedures.

4.1.1 Who can Submit a Certificate Application

The certificate application can be submitted by the subscriber or an entity representing the subscriber.

The end-user certificates can only be issued to legal person’s registered and having a valid status in the

national Brønnøysundregistrene or other applicable identification practices.

The TSP verifies that the application identifies: The subscriber (the legal person the certificate is being

issued to); the subscriber representor; the receiver of the certificate and if applicable; an administrator.

For details of what is being identified and validated see section “3.2 Initial Identity Validation” and section

“4.2 Certificate Application Processing” for requirement in the process. The certificate application is

submitted to the TSP. Only the TSP can submit certificate request to the CA after the TSP’s mandatory

process in section “4.2 Certificate Application Processing” and controls in section “3.2 Initial Identity

Validation” have been conducted.

4.1.2 Enrollment Process and Responsibilities

All certification processes are performed under the TSP control by trusted personnel in trusted roles or by

subcontractor under the control by the TSP regime. The TSP’s internal document “Monitoring and Review

of 3rd Party Services” gives a list of all subcontractors performing certification services, what services

they perform and which certificate profile (with belonging OIDs) they have a role in.

See section “1.3 PKI Participants” for roles and responsibilities Only RA operators are allowed to do the

issuances of the certificates see the RA obligation at section in “1.3.2 Registration Authorities”.

Responsibilities in the process are set according to sections “5.2 Procedural Controls” and “5.3 Personnel

Controls” and according to the TSP’s internal document “CN-GPR-58_Certification Services Procedure”.


Commfides Norge AS

4.2 Certificate Application Processing

The certification process is part of the registration service (see Appendix 2). The certificate application

process is the process receiving the certificate application till the accepted request for the certificate is

sent to the CA for issuance the certificate applications. The process includes the deliverance of the

certificate application where the certificate application might be submitted through web services or by

the physical absence of the subscriber requesting the TSP for a certificate (without a prefilled certificate

application). Included is also the TSP identification process as in section “3 Identification And

Authentication” and the verifying of the data in the application. Prior to the certificate issuance the TSP

receive and verify the subscriber consents for term and conditions according to section “4.4 Certificate

Acceptance”.

Certificate application are only accepted from registered and trusted registration services, which applying

to the general security requirements of the TSP including human resources, operational security, and

networks and privacy as specified in sections “5.3 Personnel Controls”, "6.6 Life Cycle Technical Controls",

“6.7 Network Security Controls” and “9.4 Privacy of Personal Information”. The registration data used by

external registration service providers (see section “1.3.5 Other Participants” for references to external

registration service providers) are exchanged encrypted and securely and only with recognized

registration service providers, who are enforced through the system to be authenticated.

4.2.1 Performing Identification and Authentication Functions

Identification of subscribers and subjects are submitted by and are in accordance with the section “3.2

Initial Identity”. Subcontractors performing certification services are identified according to The TSP’s

internal document “Monitoring and Review of 3rd Party Services”

4.2.2 Approval or Rejection of Certificate Applications

The TSP will approve the certificate application upon successful verifications according to CPS section “4.2

Certificate Application Processing” if non successful the TSP will reject the certificate application and

inform the applicant(s) of the result.

4.2.3 Time to Process Certificate Applications

The TSP processes the certificate applications quickly and not without undue delay. From the time

certificate application is received at the TSP, until certificate is sent out, is aimed to be less than 5 working

days. The TSP may inform about current delivery and processing times on its website.


Commfides Norge AS

4.3 Certificate Issuance

The certificate issuance process is part of the Certificate generation service (see APPENDIX 2). The

certificate issuance starts with a validated certificate request have being sent from the TSP’s Registration

service.

The TSP issue certificates securely to maintain their authenticity. The requirements for the use of the

certificate profiles are linked to a CP as defined section CPS “7.1 Certificate Profile” for certificate profiles.

In particular:

The TSP is taking measures against forgery of certificates and in cases where the TSP generates the

subjects' key pair, the TSP guarantee confidentiality during the process of generating such data.

The procedure of issuing the certificate is securely linked to the associated registration or certificate

renewal, including the provision of any subject-generated public key.

The procedure of issuing the certificate is securely linked to the generation of the key pair by the TSP;

[CPN legal person NCP] and [CPN legal person LCP]

The private key are securely passed to the registered subject; or to the TSP managing the subject's

private key; and


The secure cryptographic device containing the subscriber’s private keys (The QSCD) are securely

delivered to the registered subscriber.

The TSP ensures that the subscriber has control over its signing key.

Over the life time of the CA a distinguished name which has been used in a certificate by it, is never re-

assigned to another entity.

The details for the TSP’s certification services procedure for the end-users certificate, is described in the

the TSP’s internal document CN-GPR-58_Certification Services Procedure. This includes; registration

service, certificate generation service, dissemination service, revocation management service, revocation

status service and subject device provision service.

The CP OID’s are defined in section “7.1.6 Certificate Policy Object Identifier”

In the internal TSP document “CN-GFR-31_Records of Assets” under control of the TSP’s information

security management system. There is an overview of what smartcard including applet are used for the

QSCD or encryption device and what card and certificate management system are used by the RA or LRA


Commfides Norge AS

operators for the issuance of the certificates.

4.3.1 CA Actions during Certificate Issuance

The CA authenticates the RA request using advanced methods for verification. The CA is then verifying

the input data. If accepted the CA generates the certificate and signs it with the subordinate CA

certificate.

The certificate is generated by using the following input from the RA;

The input data regarding subject and/ or subscriber

The public key

When the certificate is generated and signed, the CA returns the certificate to the RA.

The certificate and public key are then published according to section “4.10 Certificate Status Services”

these are public information as stated in section “9.4.3 Information not Deemed Private”.

4.3.2 Notification to Subscriber by the CA of Issuance of Certificate

If the certificate is being sent physically to the subscriber, the subscriber is notified, informing that the

certificate is available for pick-up on a physical location (for instance the local post office), and then the

identification control is performed prior to the delivery of the certificate, as according to section “3.

Identification And Authentication”. If the subscriber is picking up the certificate at the TSP’s premises, the

subscriber is notified when certificate is ready for pickup.


If the certificate is being sent electronically to the subscriber, the subscriber is notified that the certificate

is being sent encrypted to the subscribers validated email.

4.4 Certificate Acceptance

The terms and conditions in the subscriber/subject agreement indicate what is deemed to constitute

acceptance of the certificate see also section “9.17 Other Provisions” under “Terms and Condition”. In

particular:

Before entering the contractual relationship with a subscriber, the TSP inform the subscriber of the terms

and conditions regarding use of the certificate as given in section “9.17 Other Provisions” under “Terms

and Condition” and in their associated PDS.

The TSP communicates the terms and conditions in the associated PDS which is public available on the

web under the control of the TSP and directly linked within the certificate. The PDS is available in English.

The TSP records the signed agreement with the subscriber (see section "5.4 Audit Logging Procedures"

under Registration, bullet point 2). The signed agreement includes:


Commfides Norge AS

Agreement to the subscriber's obligations (see section “9.17 Other Provisions” under “Terms and

Condition” and the subscriber obligation identified in section“1.3.3 Subscribers (End Entities)”)

General terms and conditions as identified in section “2 Publication And Repository

Responsibilities”

Consent to the keeping of a record by the TSP of information used in registration, subject device

provision, including whether this is to the subscriber or to the subject where they differ, and any

subsequent revocation (see sections “5.4 Audit Logging Procedures” and “5.5 Records Archival”),

the identity and any specific attributes placed in the certificate, and the passing of this

information to third parties under the same conditions as required by this policy in the case of the

TSP terminating its services.

Whether, and under what conditions, the subscriber requires and the subject consents to the

publication of the certificate.

Confirmation that the information held in the certificate is correct

Obligations applicable to subjects (see section “9.17 Other Provisions” under “Terms and

Condition” ” and the subscriber obligation identified in section “1.3.3 Subscribers (End Entities)”)

The records identified above are retained for the period of time as defined to the subscriber and

subscriber (See also section “5.5 Records Archival” regarding retention of information”)

4.4.1 Conduct Constituting Certificate Acceptance

See section “4.4 Certificate Acceptance” above.

4.4.2 Publication of the Certificate by the CA


4.4.3 Notification of Certificate Issuance by the CA to Other Entities



Commfides Norge AS

4.5 Key Pair and Certificate Usage

The obligations, key usage and limitations for the subject and subscriber are listed in CPS section “1.3.3

Subscribers (End Entities)”. The obligations for relying parties are listed in CPS section “1.3.4 Relying

Parties”.

End-user certificates are only to be used for PKI based services.

The key usage for the end-user certificates is set in the certificate profiles in the "Key Usage" field" and in

the "Extended Key Usage" see "Appendix 3, Commfides Certificate Profiles"

4.5.1 Subscriber Private Key and Certificate Usage

The section “1.3.3 Subscribers (End Entities)” is listing subscriber obligations for certificate and private

key usage.

Section “7.1.6 Certificate Policy Object Identifier” listing key usage for each certificate type, in addition

key usage is listed in each certificate itself.

4.5.2 Relying Party Public Key and Certificate Usage

The section “1.3.4 Relying Parties” is listing relying party obligations for public key and certificate usage.

Section “7.1.6 Certificate Policy Object Identifier” listing key usage for each certificate type, in addition

key usage is listed in each certificate itself.


Commfides Norge AS

4.6 Certificate Renewal

4.6.1 Circumstance for Certificate Renewal

An end-user subscriber certificate renewal can occur at any time within the certificate lifetime but can’t

occur after a certificate has expired.

The certificate can‘t have been revoked and must have a valid status according to the TSP's OCSP service.

The renewal process shall as for initial certificate process be complete, accurate and authorized.

The TSP checks the existence and validity of the certificate to be renewed and that the information used

to verify the identity and attributes of the subject are still valid. If any of the TSP terms and conditions has

changed, these are communicated to the subscriber/subject and agreed to in accordance with clause “4.4

Certificate Acceptance”, items a), b), c) and d).

The TSP may re-use existing evidences to validate the identity of subscriber and subject, given the

evidence is still valid.

The TSP issue new certificate using the subject's previously certified public key, only if its cryptographic

security is still sufficient for the new certificate's validity period and no indications exist that the subject's

private key has been compromised nor that the certificate has been revoked due to any other security

breach.

4.6.2 Who May Request Renewal

The end-user subscriber renewal request occurs under the same procedure as for initial certificate

request as given in section “4.1.1 Who can Submit a Certificate Application”.

4.6.3 Processing Certificate Renewal Requests

The end-user subscriber certificate renewal processing occurs under the same procedure as for initial

certificate process as given in section “4.1 Certificate Application”, “4.2 Certificate Application

Processing” and “4.3 Certificate Issuance” though with the same exception as in section “4.6.2 Who May

Request Renewal”.

4.6.4 Notification of New Certificate Issuance to Subscriber

Same as for section “4.3.2 Notification to Subscriber by the CA of Issuance of certificate”

4.6.5 Conduct constituting acceptance of a renewal certificate

A renewal of end-user subscriber certificate presume a valid initial agreement with subscriber and

presuming relevant changes in terms and condition has been communicated to the subscriber, the

subscriber are not required to sign or accept a new agreement under these circumstances.

To be able to identify the subscriber and to receive evidence that the subscriber has access to the existing


Commfides Norge AS

certificate to be renewed, either;

The initial requirement for identification and reception remain, see section “4.4.1 Conduct Constituting

Certificate Acceptance” and “3.2 Initial Identity Validation” or;

The subscriber proving through online web service, under the TSP’S responsibility to be in possession of

the existing certificate and using its activation code (PIN) for evidence.

4.6.6 Publication of the renewal certificate by the CA

Same as for section “4.4.2 Publication of the Certificate by the CA”

4.6.7 Notification of certificate issuance by the CA to other entities

Same as for section “4.4.3 Notification of Certificate Issuance by the CA to Other Entities”


Commfides Norge AS

4.7 Certificate Re-Key

The TSP doesn’t offer certificate re-key. (In the definition of generating a new key pair to certificate that

has not been changed, see renewal in section “4.6 Certificate Renewal”.

4.7.1 Circumstance for Certificate Re-Key


4.7.2 Who May Request Certification of a New Public Key


4.7.3 Processing Certificate Re-Keying Requests




4.7.5 Conduct Constituting Acceptance of a Re-Keyed Certificate


4.7.6 Publication of the Re-Keyed Certificate by the CA





Commfides Norge AS

4.8 Certificate Modification

The TSP doesn’t allow certificate modification.

4.8.1 Circumstance for Certificate Modification


4.8.2 Who May Request Certificate Modification


4.8.3 Processing Certificate Modification Requests




4.8.5 Conduct Constituting Acceptance of Modified Certificate


4.8.6 Publication of the Modified Certificate by the CA





Commfides Norge AS

4.9 Certificate Revocation and Suspension

Upon authorized requests the TSP revoke or suspends certificates 24 hours a day 7 days a week within 1

hour after the TSP has decided to revoke the certificate in the received request, however no more than

25 hour later than the request was received by the TSP. The CRL have always stated the next scheduled

CRL issue and are signed by the CA.

Revocation status will be made available through online certificate status protocol (OCSP) immediately

after revocation and no longer than 24 hour through certification revocation lists (CRL). Issued CRLs are

archived for a minimum of 10 years (See section “5.5.1 Types of Records Archived”) and follow the

backup procedures in accordance with section “5.5.4 Archive Backup Procedures”

The TSP publishes CRLs showing the revocation of CTE certificates and offers status checking services.

The subject, and where applicable the subscriber, of a revoked or suspended certificate, is informed of

the change of status of the certificate. Any change of status of a certificate is updated in the CRL and

OCSP.

Every CRL state a time for next scheduled CRL issue (though new CRL may be published before the stated

time of the next CRL issue). The CRL are signed by the CA.

A new CARL is generated at least once a year with a next update of at most 1 year after the issuing date.

A new CARL is generated once a CA certificate has been revoked.

4.9.1 Circumstances for Revocation

Circumstances for revoking end-user subscriber certificates

An end-user subscriber certificate is revoked if:

The TSP, a RA, a Customer, or a subscriber has reason to believe or strongly suspects that there

has been a Compromise of a subscriber’s private key;

The TSP, a RA, a Customer, or a subscriber has reason to believe that the subscriber has materially

breached a material obligation, representation, or warranty under the applicable subscriber

agreement;

The subscriber or subject agreement with the subscriber or subject has been terminated;

The TSP, a RA, a Customer, or a subscriber has reason to believe that the certificate was issued in

a manner not materially in accordance with the procedures required by the applicable CPS, the

certificate was issued to a person or entity other than the one named as the subject of the

certificate, or the certificate was issued without the authorization of the person or entity named

as the subject of such certificate;

The TSP, a RA, a Customer, or a subscriber has reason to believe that a material fact in the

certificate application is false;


Commfides Norge AS

The TSP, a RA, a Customer, or a subscriber determines that a material prerequisite to certificate

Issuance was neither satisfied nor waived;

The information within the certificate, other than Non-Verified subscriber Information, is incorrect

or has changed; or

The subscriber requests revocation of the certificate in accordance with Section “3.4 Identification

and Authentication for Revocation Request”.

The TSP’s subscriber agreements require end-user subscribers to immediately notify the TSP of a known

or suspected compromise of its private key in accordance with the procedures in Section “4.9.3

Procedure for Revocation Request”

Circumstances for revoking root certificate, subordinate CA certificate or RA permissions

The TSP may revoke root, subordinate CA certificate or RA permissions if:

The TSP discovers or has reason to believe that there has been a compromise of the root or

subordinate private key;

The agreement between the RA and the TSP has been terminated;

The TSP discovers or has reason to believe that the certificate was issued in a manner not

materially in accordance with the procedures required by the applicable CPS, the certificate was

issued to an entity other than the one named as the subject of the certificate, or the certificate

was issued without the authorization of the entity named as the subject of such certificate;

The TSP determines that a material prerequisite to certificate issuance was neither satisfied nor

waived; or

Organization/business is filed under bankruptcy according to the Norwegian Business Registry.

4.9.2 Who can Request Revocation

The following entities may request revocation of an end-user subscriber certificate:

The TSP, RA operator, LRA Operator or customer that approved the subscriber’s certificate

application may request the revocation of any end-user subscriber or administrator certificates in

accordance with Section “4.9.1 Circumstances for Revocation”.

Subscribers and subject may request revocation of their own individual certificates.

Only the TSP by its trusted personnel is entitled to request or initiate the revocation of the certificates

issued to its own CAs, RAs, or infrastructure components. The TSP initiate the revocation in accordance

with Section “4.9.1 Circumstances for Revocation”

4.9.3 Procedure for Revocation Request

Requesting revocation of end-user certificate must be communicated to the TSP. The TSP initiates the

revocation of the certificate promptly by a RA operator.


Commfides Norge AS

To request a revocation an e-mail must be sent in to [email protected] identifying the sender

and its purpose or calling at +47 21 55 62 80. The TSP e-mail and phone service for this purpose is

available 24/7.

4.9.4 Revocation Request Grace Period

Revocation requests must be submitted as promptly as possible within a commercially reasonable period

of time.

4.9.5 Time Within which CA Must Process the Revocation Request

The maximum delay between receipt of a revocation or suspension request and the decision to change its

status information being available to all relying parties is at most 24 hours.

The maximum delay between the confirmation of the revocation of a certificate, or its suspension, to

become effective and the actual change of the status information of this certificate being made available

to relying parties is at most 60 minutes.

4.9.6 Revocation Checking Requirement for Relying Parties

Relying Parties may check the status of certificates on which they wish to rely. Relying Parties may check

certificate status by consulting the most recent CRL published by the CA that issued the certificate on

which the relying party wishes to rely. See section

“4.10 Certificate Status Services”, “4.9.10 On-Line Revocation Checking Requirements” and obligations for

relying parties in section “1.3.4 Relying Parties”

4.9.7 CRL Issuance Frequency (if applicable)

CRLs for end-user subscriber certificates are published each hour with a lifetime of 5 days.

CPN Root CA publishes a new CRL for each of its Subordinate CAs within a 12 months period since last

publication and also whenever a Subordinate CA certificate is revoked. The Published CRL may have a

lifetime up to 1 year.

4.9.8 Maximum Latency for CRLs (if applicable)

The maximum delay between receipt of a revocation or suspension request and the decision to change its

status information being available to all relying parties is at most 24 hours.

The maximum delay between the confirmation of the revocation of a certificate, or its suspension, to

become effective and the actual change of the status information of this certificate being made available

to relying parties is at most 60 minutes.

4.9.9 On-Line Revocation/Status Checking Availability

The TSP provides certificate status information through query functions available through web-based

query functions accessible through the TSP’s OCSP service or the CRL.


Commfides Norge AS

4.9.10 On-Line Revocation Checking Requirements

If a relying party does not check the status of a certificate on which the relying party wishes to rely by

consulting the most recent relevant CRL, the relying party must check certificate status using the

applicable methods specified in Section “4.9.9 On-Line Revocation/Status Checking Availability”

4.9.11 Other Forms of Revocation Advertisements Available

No stipulation.

4.9.12 Special Requirements Re-Key Compromise

The TSP doesn’t offer re-key of certificates.

4.9.13 Circumstances for Suspension

The TSP doesn’t offer suspension of certificates.

4.9.14 Who can Request Suspension


4.9.15 Procedure for Suspension Request


4.9.16 Limits on Suspension Period



Commfides Norge AS

4.10 Certificate Status Services

Revocation status information is available 24/7. Procedures are established to ensure continuity in case of

unforeseen failure. Revocation information is signed by the TSP and protected by the TSP infrastructure.

The revocation status information system shall not be unavailable for more than 24 hours. The revocation

status information system includes both the service for receiving request for revocation and the

publishing service (CRL and OCSP) for revocation status. Revocation status information is made available

beyond the validity period of the certificate. The CRL and OCSP for the Root CA, Subordinate CA and

belonging end-user subscriber/subject certificates will be hosted and published until all issued certificates

are expired. Information are available free of charge, on request to the TSP, sent to

[email protected]. The CRLs are archived.

The TSP publishes CRLs showing the revocation of certificates, revocation date/time and offers status

checking services. See section “4.9.7 CRL Issuance Frequency (if applicable)” for frequency of publishing

and generation.

For the TSP CAs, subordinate CA and end-user subscriber/subject certificates CRLs are posted in the CN

repository at http://crl1.Commfides.com/

OCSP and CRL are supported. (See clause “7.3 OCSP Profile” for profile requirements of OCSP and “7.2

CRL Profile” for profile requirements of CRL)) OCSP is not supported after the certificate expiry.

Any updates to revocation status are available, and the information provided by the services is consistent

over time. The revocation status information are publicly, internationally available and free of charge.

Misuse is prohibited and will be prosecuted.

4.10.1 Operational Characteristics

No stipulation.

4.10.2 Service Availability

No stipulation.

4.10.3 Optional Features

No stipulation.

http://crl1.commfides.com/


Commfides Norge AS

4.11 End of Subscription

No stipulation.

4.12 Key Escrow and Recovery

The TSP doesn’t offer key escrow of private keys for end-user subscriber/subject certificates.

4.12.1 Key Escrow and Recovery Policy and Practices

No stipulation.

4.12.2 Session Key Encapsulation and Recovery Policy and Practices

No stipulation.


Commfides Norge AS

5. FACILITY, MANAGEMENT, AND OPERATIONAL

CONTROLS

Risk Assessment;

a) The TSP is carrying out risk assessments to identify, analyse and evaluate trust service risks taking

into account business and technical issues.

b) The TSP selects the appropriate risk treatment measures, taking account of the risk assessment

results. The risk treatment measures ensuring that the level of security is commensurate to the

degree of risk.

c) The TSP determines all security requirements and operational procedures that are necessary to

implement the risk treatment measures chosen, as documented in the information security policy

and the trust service practice statement.

d) The risk assessment are regularly reviewed and revised in accordance with the TSP’s internal

procedures and policies for risk assessment.

e) The TSP management are acquired to approve the risk assessment and accept the residual risk

identified.

Information security policy;

a) The TSP has information security policy which is approved by management and which sets out the

organization's approach to managing its information security.

b) Changes to the information security policy are communicated to third parties, where applicable.

This includes subscribers, relying parties, assessment bodies, supervisory or other regulatory

bodies. In particular:

i. The TSP's information security policy are documented, implemented and maintained including the

security controls and operating procedures for TSP facilities, systems and information assets

providing the services. The TSP publishes and communicates this information security policy to all

employees who are impacted by it and to relevant third parties.

ii. The TSP retains the overall responsibility for conformance with the procedures prescribed in its

information security policy, even when the TSP functionality is undertaken by outsourcers. TSP

has defined the outsourcers’ liability and ensures those outsourcers are bound to implement any

controls required by the TSP.

iii. The TSP information security policy and inventory of assets for information security (see “Asset

management”) are reviewed at planned intervals or if significant changes occur to ensure their

continuing suitability, adequacy and effectiveness. Any changes impacting on the level of security

provided is approved by Commfides Certificate Advisory Board. The configurations of the TSP’s

systems are regularly checked for changes which violate the TSPs security policies.


Commfides Norge AS

Asset management;

a) The TSP ensures an appropriate level of protection of its assets including information assets. The

TSP maintains an inventory of all information assets and assigns a classification consistent with the

risk assessment.

b) All media are handled securely in accordance with requirements of the information classification

scheme. Media containing sensitive data are securely disposed of when no longer required.

5.1 Physical Controls

5.1.1 Site Location and Construction

The TSP’s certification services are conducted within the TSP’s facilities, in the TSP’s disaster site or within

the facilities of controlled and accepted subcontractors. The certification services are conducted within

physically protected environment designed to deter, prevent, and detect covert or overt penetration. The

TSPs facilities have physical security tiers as described in section “5.1.2 Physical Access”

5.1.2 Physical Access

The TSP control physical access to components of the TSP's system whose security is critical to the

provision of its trust services and minimize risks related to physical security. In particular:

a) Physical access to components of the TSP's system whose security is critical to the provision of its

trust services is limited to authorized individuals. Criticality is identified through risk assessment,

or through application security requirements, as requiring a security protection.

b) Controls are implemented to avoid loss, damage or compromise of assets and interruption to

business activities;

c) Controls are implemented to avoid compromise or theft of information and information

processing facilities; and

d) Components that are critical for the secure operation of the trust service are located in protected

security perimeter with physical protection against intrusion, controls on access through the

security perimeter and alarms to detect intrusion.

Certificate generation and revocation management;

e) The facilities concerned with certificate generation and revocation management are operated in

an environment which physically protects the services from compromise through unauthorized

access to systems or data.


Commfides Norge AS

f) Every entry to the physically secure area is subject to independent oversight and non-authorized

persons are accompanied by an authorized person whilst in the secure area. Every entry and exit

is logged.

g) Physical protection is achieved through the creation of clearly defined security perimeters (i.e.

physical barriers) around the certificate generation and revocation management services. Any

parts of the premises shared with other organizations are outside this perimeter.

h) Physical and environmental security controls are implemented to protect the facility housing

system resources, the system resources themselves, and the facilities used to support their

operation. The TSP's physical and environmental security policy for systems concerned with

certificate generation and revocation management services address the physical access control,

natural disaster protection, fire safety factors, failure of supporting utilities (e.g. power,

telecommunications), structure collapse, plumbing leaks, protection against theft, breaking and

entering, and disaster recovery.

i) Other functions relating to TSP operations are supported within the same secured area, access is

limited to authorized personnel.

j) Root CA private keys are held and used physically isolated from normal operations such that only

designated trusted personnel have access to the keys for use in signing subordinate CA

certificates.

5.1.3 Power and Air Conditioning

The CTE are under reasonable precautions to provide adequate power and air conditioning. Generator,

UPS and redundant air conditioning are installed.

5.1.4 Water Exposures

The CTE are under reasonable precautions to minimize the impact of water exposure to the systems

including surveillance and alarm.

5.1.5 Fire Prevention and Protection

The CTE are under reasonable precautions to alarm damaging exposure to flame or smoke. The fire

prevention and protection measures have been designed to comply with local fire safety regulations.

Automatic fire alarms connected to local fire station are installed.

5.1.6 Media Storage

All media containing production software and data, audit, archive, or backup information is stored within

the TSP facilities or in a secure off-site storage facility with appropriate physical and logical access


Commfides Norge AS

controls designed to limit access to authorized personnel and protect such media from accidental

damage (e.g., water, fire, and electromagnetic).

5.1.7 Waste Disposal

Sensitive documents and materials are shredded or destroyed before disposal. Media used to collect or

transmit sensitive information are rendered unreadable before disposal.

5.1.8 Off-Site Backup

The TSP performs routine backups of critical system data, audit log data, and other sensitive information

of the TSP system and data. Offsite backup media are stored in a physically secure manner.

5.2 Procedural Controls

5.2.1 Trusted Roles

The TSP's system access is limited to authorized individuals. The TSP administrating user access of

operators, system administrators and system auditors. The administration includes user account

management and timely modification or removal of access. TSP personnel are accountable for their

activities.

Trusted personnel include personnel that have access to or control authentication or cryptographic

operations that may materially affect:

• The validation of information in certificate applications;

• The acceptance, rejection, or other processing of certificate Applications, revocation requests, or

renewal requests, or enrolment information;

• The issuance, or revocation of certificates, including personnel having access to restricted portions of its

repository; or

• The handling of subscriber information or requests.

Trusted personnel are considered to be personnel having a defined trusted role within the CTE.

Trusted personnel must successfully complete the personnel screening defined in internal personnel

procedures within the TSP. Trusted personnel must undergo required training for each role prior to

access to system and restricted area within the CTE. Changes in roles and personnel are recorded.

5.2.2 Number of Persons Required per Task

Critical operational procedures are carried out with the participation of more than one individual

personnel in a defined trusted role.

Transactions regarding the establishment, renewal and revocation of the TSP’s root and subordinate


Commfides Norge AS

certificate, are carried out with the participation of at least two individual personnel in defined trusted

roles.

5.2.3 Identification and Authentication for Each Role

The TSP's system accesses are limited to authorized individuals. In particular:

TSP personnel are identified and authenticated before using critical applications related to the service.

For all personnel to become trusted personnel, verification of identity is performed through the personal

(physical) presence of such personnel before the trusted personnel performing HR or security functions

and a check of well-recognized forms of identification such as passports and driver’s licenses.

The TSP ensures that personnel have achieved trusted status and departmental approval has been given

before such personnel are:

• granted access to the required facilities; and

• issued electronic credentials to access and perform specific functions on the TSP’s CA, RA, or other

IT systems.

5.2.4 Roles Requiring Separation of Duties

The TSP's system access is limited to authorized individuals. In particular:

Access to information and application system functions are restricted in accordance with the access

control policy. The TSP system providing sufficient computer security controls for the separation of

trusted roles identified in TSP's practices, including the separation of security administration and

operation functions. Particularly, use of system utility programs is restricted and controlled.

All trusted roles are defined in order to maintain a high level of segregation to be free from conflict of

interest that might prejudice the impartiality of the TSP operations.


Commfides Norge AS

5.3 Personnel Controls

The TSP ensures that employees and subcontractors support the trustworthiness of the TSP's operations.

In particular:

a) Security roles and responsibilities, as specified in the TSP's information security policy, is

documented in job descriptions or in documents available to all concerned personnel. Trusted

roles, on which the security of the TSP's operation is dependent, are clearly identified. Trusted

roles are named by the management and accepted by the management and the person to fulfil

the role.

b) TSP personnel (both temporary and permanent) have job descriptions defined from the view

point of roles fulfilled with segregation of duties and least privilege, determining position

sensitivity based on the duties and access levels, background screening and employee training and

awareness. Where appropriate, these differentiate between general functions and TSP specific

functions. These include skills and experience requirements.

c) Personnel exercise administrative and management procedures and processes that are in line

with the TSP's information security management procedures.

d) All TSP personnel in trusted roles is free from conflict of interest that might prejudice the

impartiality of the TSP operations.

e) Trusted roles includes roles that involve the following responsibilities:

i. Security Officers: Overall responsibility for administering the implementation of the

security practices.

ii. System Administrators: Authorized to install, configure and maintain the TSP

trustworthy systems for service management. This includes recovery of the system.

iii. System Operators: Responsible for operating the TSP trustworthy systems on a day-to-

day basis. Authorized to perform system backup.

iv. System Auditors: Authorized to view archives and audit logs of the TSP trustworthy

systems.

f) TSP personnel are formally appointed to trusted roles by senior management responsible for

security requiring the principle of "least privilege" when accessing or when configuring access

privileges.


Commfides Norge AS

g) Personnel don’t have access to the trusted functions until any necessary checks are completed.

5.3.1 Qualifications, Experience, and Clearance Requirements


In particular:

The TSP employs staff and, if applicable, subcontractors, who possess the necessary expertise, reliability,

experience, and qualifications and who have received training regarding security and personal data

protection rules as appropriate for the offered services and the job function.

Personnel seeking to become Trusted Persons must present proof of the requisite background,

qualifications, and experience needed to perform their prospective job responsibilities competently and

satisfactorily, as well as proof of any government clearances, if any, necessary to perform certification

services under government contracts.

5.3.2 Background Check Procedures

All TSP personnel put in a position with a trusted, undergoes a background check described in the TSP’s

internal policy and internal personnel procedures, to maintain the trustworthiness of the TSP's

operations.

5.3.3 Training Requirements


In particular:

TSP personnel are required to be able to fulfil the requirement of "expert knowledge, experience and

qualifications" through formal training and credentials, or actual experience, or a combination of the two.

This includes regular (at least every 12 months) updates on new threats and current security practices.

Managerial personnel possesses experience or training with respect to the trust service that is provided,

familiarity with security procedures for personnel with security responsibilities and experience with

information security and risk assessment sufficient to carry out management functions.

All personnel performing duties with respect to the operation of TSP shall receive training in the following

areas:

• CA/RA security principals and mechanisms;

• All PKI software used in the CA system;

• All PKI duties they are expected to perform; and

• Disaster recovery and business continuity procedures.


Commfides Norge AS

5.3.4 Retraining Frequency and Requirements

The TSP provides refresher training and updates to its personnel to the extent and frequency required to

ensure that such personnel maintain the required level of proficiency to perform their job responsibilities

competently and satisfactorily. Periodic security awareness training is provided on an ongoing basis.

5.3.5 Job Rotation Frequency and Sequence

No Stipulation.

5.3.6 Sanctions for Unauthorized Actions


In particular: Appropriate disciplinary sanctions are applied to personnel violating TSP policies or

procedures.

The TSP takes appropriate administrative and disciplinary actions against personnel who perform actions

not authorized in the CP, CPS or other standards set up by the TSP.

5.3.7 Independent Contractor Requirements

In limited circumstances, independent subcontractors or consultants are used to fill trusted positions. Any

such subcontractor or consultant is held to the same functional and security criteria that apply to the

TSP’s employees in a comparable position.

Independent subcontractors and consultants who have not completed the procedures specified in

Section “5.3.1 Qualifications, Experience, and Clearance Requirements” are permitted access to the TSP’s

secure facilities only to the extent they are escorted and directly supervised by trusted personnel.

5.3.8 Documentation Supplied to Personnel

The TSP provides and makes available to its CA and RA personnel, the relevant sections of the CP, CPS,

the TSP’s standards and any applicable statutes.


Commfides Norge AS

5.4 Audit Logging Procedures

The TSP records and keeps accessible for an appropriate period of time, including after the activities of

the TSP has ceased, all relevant information concerning data issued and received by the TSP, in particular,

for the purpose of providing evidence in legal proceedings and for the purpose of ensuring continuity of

the service. In particular:

The confidentiality and integrity of current and archived records concerning operation of services

are maintained.

Records concerning the operation of services are completely and confidentially archived in

accordance with disclosed business practices.

Records concerning the operation of services are made available if required for the purposes of

providing evidence of the correct operation of the services for the purpose of legal proceedings.

The precise time of significant TSP environmental, key management and clock synchronization

events are recorded. The time used to record events as required in the audit log is synchronized

with UTC at least once a day.

Records concerning services are held for a period of time as appropriate for providing necessary

legal evidence and as notified in the TSP terms and conditions.

The events are logged in a way that they cannot be easily deleted or destroyed (except if reliably

transferred to long-term media) within the period of time that they are required to be held.

All security events are logged, including changes relating to the security policy, system start-up and

shutdown, system crashes and hardware failures, firewall and router activities and PKI system access

attempts.

Registration

All events related to registration including requests for certificates, renewals or revocations are

logged.

All registration information including the following is recorded:

o Type of document(s) presented by the applicant to support registration;

o Record of unique identification data, numbers, or a combination thereof of identification

documents, if applicable;

o Storage location of copies of applications and identification documents, including the

signed subscriber agreement;

o Any specific choices in the subscriber agreement;

o Identity of entity accepting the application;

o Method used to validate identification documents, if any; and

o Name of receiving TSP and/or submitting Registration Authority, if applicable.

The TSP maintains the privacy of subject information. (See CPS section “9.4 Privacy of Personal


Commfides Norge AS

Information”)

Certificate generation

The TSP logs all events relating to the life-cycle of CA keys.

The TSP logs all events relating to the life-cycle of certificates.

The TSP logs all events relating to the life cycle of keys managed by the CA, including any subject

keys generated by the CA.

Revocation management

The TSP logs all requests and reports relating to revocation, as well as the resulting action.

Subject device provision

The TSP logs all events relating to the preparation of QSCDs.

General

The TSP records all relevant information concerning data issued and received and logs all events

relating to the EU qualified certificate registration, generation, dissemination, and when

applicable, revocation management and device preparation.

The information is maintained as necessary to meet legal requirements beyond the termination of

the TSP.

The TSP documents how this information is accessible.

The TSP documents precisely the period of retention of the information mentioned above in its

practices statements and indicate which information is subject to be handed-over through its

termination plan.

The TSP records and keep accessible for an appropriate period of time, including after the

activities of the qualified trust service provider have ceased, all relevant information concerning

data issued and received by the qualified trust service provider, in particular, for the purpose of

providing evidence in legal proceedings and for the purpose of ensuring continuity of the service.

The TSP is, without undue delay but in any event within 24 hours after having become aware of it,

notifying the supervisory body and, where applicable, other relevant bodies, such as the

competent national body for information security or the data protection authority, of any breach

of security or loss of integrity that has a significant impact on the trust service provided or on the

personal data maintained therein.

Where the breach of security or loss of integrity is likely to adversely affect a natural or legal

person to whom the trusted service has been provided, the trust service provider also notify the

natural or legal person of the breach of security or loss of integrity without undue delay.


Commfides Norge AS

5.4.1 Types of Events Recorded

The TSP manually or automatically logs the following significant events:

CA key life cycle management events, including:

o Key generation, backup, storage, recovery, archival, and destruction; and

o Cryptographic device life cycle management events.

CA and subscriber certificate life cycle management events, including:

o Certificate applications, renewal and revocation:

o Successful or unsuccessful processing of requests: and

o Generation and issuance of certificates and CRLs.

o All events relating to the preparation of QSCDs.

Security-related events including:

o Successful and unsuccessful PKI system access attempts;

o PKI and security system actions performed by the TSP personnel;

o Security sensitive files or records read, written or deleted;

o Security profile changes;

o System crashes, hardware failures and other anomalies;

o Firewall and router activity; and

o CA facility visitor entry/exit.

o Log entries include the following elements:

o Date and time of the entry;

o Serial or sequence number of entry, for automatic journal entries; and

o Identity of the entity making the journal entry

5.4.2 Frequency of Processing Log

Audit logs are examined regularly for significant security and operational events. In addition, the TSP

reviews its audit logs for suspicious or unusual activity in response to alerts generated based on

irregularities and incidents within the TSP CA and RA systems.

Audit log processing consists of a review of the audit logs and documentation for all significant events in

an audit log summary. Actions taken based on audit log reviews are documented.

5.4.3 Retention Period for Audit Log

Retention period for audit logs are defined in the TSP’s internal procedures.

5.4.4 Protection of Audit Log

Electronic and manual audit log files are protected from unauthorized viewing, modification, deletion, or

other tampering through the use of physical and logical access controls.


Commfides Norge AS

5.4.5 Audit Log Backup Procedures

Incremental backups of audit logs are created regularly and full backups are performed regularly

according to internal backup procedures.

5.4.6 Audit Collection System (Internal vs. External)

Automated audit data is generated and recorded at the application, network and operating system level.

Manually generated audit data is recorded by the TSP trusted personnel.

5.4.7 Notification to Event-Causing Subject

The TSP will, without undue delay but in any event within 24 hours after having become aware of it,

notify the supervisory body and, where applicable, other relevant bodies, such as the competent national

body for information security or the data protection authority, of any breach of security or loss of

integrity that has a significant impact on the trust service provided or on the personal data maintained

therein.

Where the breach of security or loss of integrity is likely to adversely affect a natural or legal person to

whom the trusted service has been provided, the TSP will also notify the natural or legal person of the

breach of security or loss of integrity without undue delay.

5.4.8 Vulnerability Assessments

The TSP does regularly vulnerability assessment and penetration testing to its system to maintain the

highest level of security and trust.


Commfides Norge AS

5.5 Records Archival

The TSP retains the following for at least ten years after any certificate based on these records ceases:

Log of all events relating to the life cycle of keys managed by the CA, including any subject key

pairs generated by the CA

Documentation as identified in section "4.4 Certificate Acceptance"

5.5.1 Types of Records Archived

In addition to the audit logs specified in Section “5.4.1 Types of Events Recorded”, the TSP maintains

records that include documentation of:

The TSP compliance with the CPS and other obligations under its agreements with their

subscribers, and

Actions and information that are material to each certificate Application and to the creation,

issuance, use, revocation, expiration and renewal of all certificates it issues from the TSP CAs.

The TSP records certificate life cycle events including:

The identity of the subscriber named in each certificate;

The identity of persons requesting certificate revocation;

Other facts represented in the certificate;

Time stamps

5.5.2 Retention Period for Archive

Records associated with a certificate are retained for at least the time periods set forth below following

the date the certificate expires or is revoked:

Ten (10) years;

If necessary, the TSP may implement longer retention periods in order to comply with applicable

laws.

5.5.3 Protection of Archive

The TSP protects its archived records compiled in section “5.5.1 Types of Records Archived” so that only

authorized Trusted Personnel are permitted to access archived data.

Electronically archived data is protected against unauthorized viewing, modification, deletion, or other

tampering through the implementation of appropriate physical and logical access controls. The media

holding the archive data and the applications required to process the archive data are maintained to

ensure that the archived data can be accessed for the time period set forth in Section “5.5.2 Retention

Period for Archive”

5.5.4 Archive Backup Procedures

The TSP incrementally backs up electronic archives of its issued certificate information on a daily basis

and performs full backups regularly based on internal procedures.


Commfides Norge AS

5.5.5 Requirements for Time-Stamping of Records

Certificates, CRLs, and other revocation database entries contain time and date information.

5.5.6 Archive Collection System (Internal or External)

No stipulation.

5.5.7 Procedures to Obtain and Verify Archive Information

See section “5.5.3 Protection of Archive”.

5.6 Key Changeover

The TSP CA key pairs are retired from service at the end of their respective maximum lifetimes as defined

in Section “6.3.2 Certificate Operational Periods and Key Pair Usage Periods”. The TSP’s CA certificates

may be renewed as long as the cumulative certified lifetime of the CA key pair does not exceed the

maximum CA key pair lifetime. New CA key pairs will be generated as necessary, for example to replace

CA key pairs that are being retired, to supplement existing, active key pairs and to support new services in

accordance with Section “6.1 Key Pair Generation and Installation”


Commfides Norge AS

5.7 Compromise and Disaster Recovery

5.7.1 Incident and Compromise Handling Procedures

Incident management:

System activities concerning access to IT systems, use of IT systems and service requests are monitored.

In particular:

a) Monitoring activities takes into account the sensitivity of any information collected or analysed.

b) Abnormal system activities that indicate a potential security violation, including intrusion into the

TSP network, are being detected and reported as alarms.

c) The TSP IT systems monitors the following events:

a. Start-up and shutdown of the logging functions; and

b. Availability and utilization of needed services with the TSP network.

d) The TSP is acting in a timely and co-ordinated manner in order to respond quickly to incidents and

to limit the impact of breaches of security. The TSP appoints trusted role personnel to follow up

on alerts of potentially critical security events and ensures that relevant incidents are reported in

line with the TSP's procedures.

e) The TSP uses procedures to notify the appropriate parties in line with the applicable regulatory

rules of any breach of security or loss of integrity that has a significant impact on the trust service

provided and on the personal data maintained therein within 24 hours of the breach being

identified.

f) Where the breach of security or loss of integrity is likely to adversely affect a natural or legal

person to whom the trusted service has been provided, the TSP also notifies the natural or legal

person of the breach of security or loss of integrity without undue delay.

g) The TSP systems are monitored including the monitoring or regular review of audit logs to identify

evidence of malicious activity implementing automatic mechanisms to process the audit logs and

alert personnel of possible critical security events.

h) The TSP addresses any critical vulnerability not previously addressed by the TSP, within a period of

48 hours after its discovery. If this is cost effective given the impact, the TSP creates and

implements a plan to mitigate the vulnerability or the TSP documents the factual basis for the

TSP's determination that the vulnerability does not require remediation.

i) Incident reporting and response procedures are being employed in such a way that damage from

security incidents and malfunctions are minimized.

Disaster Recovery /Business continuity management;

The TSP operates a disaster recovery site. The TSP has a developed, implemented and tested a disaster

recovery plan to mitigate the effects of any kind of natural or man-made disaster. The plan is regularly


Commfides Norge AS

tested, verified, and updated to be operational in the event of a disaster.

Detailed disaster recovery plans are in place to address the restoration of information systems services

and key business functions. The TSP disaster recovery site has implemented the physical security

protections and operational controls to provide for a secure and effective backup operational setup.

The TSP has the capability to restore or recover operations within twenty four (24) hours following a

disaster with, at a minimum, support for the following functions:

Certificate revocation; and

Publication of revocation information

A disaster recovery plan has been designed to provide full recovery within one week following disaster

occurring at the TSPs’ primary site. The TSP tests its equipment at its primary site to support CA/RA

functions following all but a major disaster that would render the entire facility inoperable. Results of

such tests are reviewed and kept for audit and planning purposes. Where possible, operations are

resumed at the TSPs’ primary site as soon as possible following a major disaster.

The TSP maintains offsite backups of important CA information for the TSPs’ CAs. Such information

includes, but is not limited to: application logs, certificate application data, audit data (per section “8

Compliance Audit and Other Assessments”), and database records for all certificates issued.

5.7.2 Computing Resources, Software, and/or Data are Corrupted

TSP systems data backup and recovery:

TSP system data backup necessary to resume CA operations are backed up and stored in safe places and

suitable to allow the TSP to timely go back to operations in case of incident/disasters.

Back-up copies of essential information and software are taken regularly. Adequate back-up facilities is

provided to ensure that all essential information and software can be recovered following a disaster or

media failure. Back-up arrangements are regularly tested to ensure that the TSP meets the requirements

of business continuity plans.

Backup and restore functions are performed by the relevant trusted roles specified in section "5.3

Personnel Controls" and "5.2 Procedural Controls".

In the event of the corruption of computing resources, software, and/or data, such an occurrence is

reported to the TSP and the TSP’s incident handling procedures are enacted. Such procedures require

appropriate escalation, incident investigation, and incident response. If necessary, the TSP’s key

compromise or disaster recovery procedures will be enacted.

5.7.3 Entity Private Key Compromise Procedures

CA key compromise:

The TSP's business continuity plan and disaster recovery plan addresses the compromise, loss or

suspected compromise of a CA's private key as a disaster and the planned processes is in place.


Commfides Norge AS

Following a disaster, the TSP where practical, takes steps to avoid repetition of a disaster.

In the case of compromise the TSP:

o Informs the following of the compromise: all subscribers and other entities with which the

TSP has agreements or other form of established relations. This information will be made

available to other relying parties;

o Indicate that certificates and revocation status information issued using this CA key may

no longer be valid; and

o Revoke any CA certificate that has been issued for the compromised TSP when a TSP is

informed of the compromise of another CA. The CA will generate a new key pair in

accordance with Section “5.6 Key Changeover”, except where the CA is being terminated

in accordance with Section “5.8 CA or RA Termination”.

o Commercially reasonable efforts will be made to provide additional notice of the

revocation to all affected CTE Participants; and

o The CA will generate a new key pair in accordance with Section “5.6 Key Changeover”,

except where the CA is being terminated in accordance with Section “5.8 CA or RA

Termination”.

Algorithm compromise:

Should any of the algorithms, or associated parameters, used by the TSP or its subscribers become

insufficient for its remaining intended usage the TSP:

o Inform all subscribers and relying parties with whom the TSP has agreement or other form

of established relations. In addition, this information is made available to other relying

parties; and

o Schedule a revocation of any affected certificate.

5.7.4 Business Continuity Capabilities after a Disaster

See section “5.7.1 Incident and Compromise Handling Procedures” above.


Commfides Norge AS

5.8 CA or RA Termination

CA Termination

In the event that it is necessary for the TSP to cease the CTE CA operation, the TSP makes a commercially

reasonable effort to notify subscribers, relying parties, and other affected entities of such termination in

advance of the CA termination. Where CA termination is required, the TSP develops a termination plan to

minimize disruption to customers, subscribers, and relying parties. Such termination plans may address

the following, as applicable:

Provision of notice to parties affected by the termination, such as subscribers, relying parties, and

customers, informing them of the status of the CA;

Handling the cost of such notice;

The revocation of the certificate issued to the CA by the TSP;

The preservation of the CA’s archives and records for the time periods required in Section “5.5

Records Archival”;

The continuation of subscriber and customer support services;

The continuation of revocation services, such as the issuance of CRLs or the maintenance of online

status checking services;

The revocation of unexpired un-revoked certificates of end-user subscribers and subordinate CAs,

if necessary;

The payment of compensation (if necessary) to subscribers whose unexpired un-revoked

certificates are revoked under the termination plan or provision, or alternatively, the issuance of

replacement certificates by a successor CA;

Disposition of the CA’s private key and the hardware tokens containing such private key; and

Provisions needed for the transition of the CA’s services to a successor CA.

All relevant TSPs partners receive advance notification. The TSP:

Inform subscribers, relying parties and other CAs about its intention to end operation, with no less

than 6 months’ notice;

Make publicly available information about its intention to end operations, with no less than 3

months’ notice;

Keep all relevant databases, archives, records and documents, for these to be made available on

request for a commercial reasonable period of time, not less than 10 years after CA termination.

The TSP’s internal document “CN-GPR-61 Commfides CA Termination and termination plans” gives the

detailed CA termination plans.


Commfides Norge AS

6. TECHNICAL SECURITY CONTROLS

6.1 Key Pair Generation and Installation

Appropriate security controls are in place for the management of any cryptographic keys and any

cryptographic devices throughout their lifecycle.

Certificate generation;

The CA generates keys securely and the private key is kept secret.

a) CA key pair generation and the subsequent certification of the public key are undertaken in a

physically secured environment by personnel in trusted roles under dual control. The number of

personnel authorized to carry out this function are kept to a minimum and are consistent with the

CA's practices.

b) Before expiration of its CA certificate which is used for signing subject keys, the CA shall generate

a new certificate for signing subject key pairs and shall apply all necessary actions to avoid

disruption to the operations of any entity that may rely on the CA certificate. The new CA

certificate shall also be generated and distributed in accordance with this policy. The TSP’s

internal document “CN-GPR-62 Commfides CA Expiration plans” gives the detailed CA expiration

plans.

c) These operations shall be performed with a suitable interval between certificate expiry date and

the last certificate signed to allow all parties that have relationships with the TSP (subjects,

subscribers, relying parties, CAs higher in the CA hierarchy, etc.) to be aware of this key

changeover and to implement the required operations to avoid inconveniences and malfunctions.

This does not apply ceasing operations before own certificate-signing certificate expiration date.

d) The TSP has a documented procedure for conducting CA key pair generation for all CAs, whether

root CAs or subordinate CAs, including CAs that issue certificates to end-users. This procedure

shows the following:

i. Roles participating in the ceremony (internal and external from the organization);

ii. Functions performed by every role and in which phases;

iii. Responsibilities during and after the ceremony; and

iv. Requirements of evidence collected at the ceremony.

e) The TSP has produced a report proving that the ceremony was carried out in accordance with the

stated procedure and that the integrity and confidentiality of the key pair is ensured. This report is

signed :

i. For root CA: by the trusted role responsible for the security of the TSP's key

management ceremony and a trustworthy person independent of the TSP


Commfides Norge AS

management as witness that the report correctly records the key management

ceremony as carried out.

ii. For subordinate CAs: by the trusted role responsible for the security of the TSP's

key management ceremony as witness that the report correctly records the key

management ceremony as carried out.

Certificate generation and dissemination:

f) CA signature verification (public) keys are available to relying parties in a manner that assures the

integrity of the CA public key and authenticates its origin.

Subject device provision:

g) The subject's private key is delivered to the subject's device in a manner such that the secrecy and

integrity of the key is not compromised. If the TSP or any of its designated RAs become aware that

a subject's private key has been communicated to an unauthorized person or an organization not

affiliated with the subject, then the TSP shall revoke all certificates that include the public key

corresponding to the communicated private key.

h) The CA deletes all copies of a subject private key after delivery of the private key to the subject,

except for conditions as described in section "4.12 Key Escrow and Recovery".

i) The TSP secures the issuance of a secure cryptographic device to the subject. In particular:

i. Secure cryptographic device preparation are done securely.

ii. Secure cryptographic device are securely stored and distributed.



j) The TSP verifies that the device is certified as a QSCD.


k) The certificate request process ensures that the public key to be certified is from a key pair

generated by a QSCD;


l) The TSP monitors the QSCD certification status until the end of the validity period of the

certificate and takes appropriate measures in case of modification of this status. Such measures

are documented in this CPS.

For the signature algorithms and parameters employed the CA key pair generation is performed using

algorithm SHA256 as specified in ETSI TS 119 312 for the CA's signing purposes. The selected key length


Commfides Norge AS

and algorithm for CA signing key is 2048bits as specified in ETSI TS 119 312 for the CA's signing purposes.

Thumbprint algorithm is SHA1.

See section “7.1.3 Algorithm Object Identifiers” and “Appendix 3, Commfides Certificate Profiles”.

6.1.1 Key Pair Generation

The CA key pair generation is performed by multiple pre-selected, trained and trusted individuals using

trustworthy systems and processes that provide for the security and required cryptographic strength for

the generated keys.

Generation of end-user subscriber key pairs see section “6.1.2 Private Key Delivery to Subscriber”

The TSP generates its CA pair’s keys using hardware cryptographic modules that meet industry standards

for its principal CAs, root and issuing CAs. Currently the TSPs’ HSM is granted FIPS PUB 140-2 level 3.

6.1.2 Private Key Delivery to Subscriber


End-user subscriber key pairs are generated and delivered at a QSCD under the control of the TSP then

securely distributed to the subscriber. The TSP may use a subcontractor (commercial delivery service) for

this distribution (see section “1.3.5 Other Participants”).


End-user subscriber key pairs are generated and delivered on an encrypted software device under the

control of the TSP then sent encrypted to the subscriber via electronic channels.

[CPN legal person NCP+], [CPN legal person NCP] and [CPN legal person LCP]

The PIN (activation data) required to activate the private keys on the certificates is generated by the TSP

system. The PIN (activation data) is distributed securely and sent to the subscriber using a distribution

route separated from the associated certificate.

6.1.3 Public Key Delivery to Certificate Issuer

The public key is transferred encrypted together with the CSR from the chip to the CA.

6.1.4 CA Public Key Delivery to Relying Parties

The TSP’s root CA certificate may be downloaded by subscribers and relying parties from the TSP’s web

site, or can be distributed via alternative channels (e-mail messages, media, etc.). The TSP generally

provides the full certificate chain (including the issuing CA and any CAs in the chain) to the end-user

subscriber upon certificate issuance.

6.1.5 Key Sizes

The TSP’s subordinate CA key pairs are 2048 bit SHA256 RSA. The TSP’s end-user subscriber key pairs are


Commfides Norge AS

2048 bit SHA256RSA. CPN RootSHA256 CA is 2048 bit SHA256RSA.

6.1.6 Public Key Parameters Generation and Quality Checking

No stipulation.

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

X.509 version 3 certificates are generally populated in accordance with RFC 5280: Internet X.509 public

key infrastructure certificate and CRL profile. The key usage extensions in X.509 class 3 certificates are

generally configured so as to set and clear bits and the criticality field. See Appendix 3.


Commfides Norge AS

6.2 Private Key Protection and Cryptographic Module Engineering Controls

In addition to requirements in section “6.1 Key Pair Generation and Installation” the following particular

requirements apply:

a) CA key pair generation is carried out within a secure cryptographic device which:

i. Is a trustworthy system which is assured to EAL 4 or higher in accordance with ISO/IEC

15408.; or

ii. Meets the requirements identified in ISO/IEC 19790 or FIPS PUB 140-2 level 3. The secure

cryptographic device is as per “i” above.

b) The CA private signing key is held and used within a secure cryptographic device as defined in a)

above.

c) When outside the secure cryptographic device (see item B) above) the CA private key shall be

protected in a way that ensures the same level of protection as provided by the secure

cryptographic device.

d) The CA private signing key is backed up, stored and recovered only by personnel in trusted roles

using, at least, dual control in a physically secured environment. The number of personnel

authorized to carry out this function are kept to a minimum and are consistent with the CA's

practices.

e) Copies of the CA private signing keys are subject to the same or greater level of security controls

as keys currently in use.

f) Where the CA private signing keys and any copies are stored in a dedicated secure cryptographic

device, access controls are in place to ensure that the keys are not accessible outside this device.

The CA private signing keys stored on the CA's secure cryptographic device are destroyed upon device

retirement.

The TSP has implemented a combination of physical, logical, and procedural controls to ensure the

security of the TSP’s CA private keys.

Logical and procedural controls are described in CPS section "6.2 Private Key Protection and

Cryptographic Module Engineering Controls”.

Physical access controls are described in section “5.1 Physical Controls”

6.2.1 Cryptographic Module Standards and Controls

The TSP uses hardware cryptographic modules that meet industry standards for its Principal CAs, Root

and Issuing CAs. Currently the TSP’s HSM is granted FIPS PUB 140-2 level 3.

6.2.2 Private Key (n out of m) Multi-Person Control

For CA private key and subordinate CA private keys 2 of 4 trusted persons in trusted roles must be

present during key ceremonies.


Commfides Norge AS

6.2.3 Private Key Escrow

The TSP doesn’t offer Key Escrow for end-user certificate.

6.2.4 Private Key Backup

The TSP creates backup copies of CA private keys for routine recovery and disaster recovery purposes.

Such keys are stored in encrypted form. Cryptographic modules used for CA private key storage meet the

requirements of Section "6.2.1 Cryptographic Module Standards and Controls".

Modules containing onsite backup copies of CA private keys are subject to the requirements of sections

“5.1 Physical Controls” and "6.2.1 Cryptographic Module Standards and Controls"

Modules containing disaster recovery copies of CA private keys are subject to the requirements of “5.7

Compromise and Disaster Recovery”.

For the backup of end-user subscriber private keys, see section “6.2.3 Private Key Escrow”

6.2.5 Private Key Archival

When the TSPs’ CA key pairs reach the end of their validity period, such CA key pairs will be archived for a

period of at least 5 years. Procedural controls prevent archived CA key pairs from being returned to

production use. Upon the end of the archive period, archived CA private keys will be securely destroyed

in accordance with Section "6.2.10 Method of Destroying Private Key".

The TSP does not archive copies of subscriber private keys, except for separate encryption keys; see

section "6.2.3 Private Key Escrow".

6.2.6 Private Key Transfer into or from a Cryptographic Module

The TSP generates CA key pairs on the hardware cryptographic modules in which the keys will be used.

The TSP additionally makes copies of such CA key pairs for routine recovery and disaster recovery

purposes. In such cases where CA key pairs are backed up to another hardware cryptographic module,

such key pairs are transported between modules in encrypted form.

6.2.7 Private Key Storage on Cryptographic Module

All CA private keys and subordinate private keys are held within secure cryptographic devices.

6.2.8 Method of Activating Private Key

All the TSP participants are required to protect the activation data for their private keys against loss,

theft, modification, unauthorized disclosure, or unauthorized use.


Commfides Norge AS

End-user subscriber private keys

This section applies the CTE Standards for protecting activation data for end-user subscribers’ private

keys to all CTE Member’s Subdomains. In addition, subscribers have the option of using enhanced private

key protection mechanisms available today including the use of smart cards, biometric access devices,

and other hardware tokens to store private keys. The use of two factor authentication mechanisms is

implemented.

The TSP recommends that the subscriber of end-user subscriber certificates use enhanced private key

protection mechanisms available today including the use of smart cards, biometric access devices, and

other hardware tokens to store private keys. When deactivated, private keys shall be kept in encrypted

form only.

6.2.9 Method of Deactivating Private Key

The TSPs’ CA private keys are deactivated when removed from the token reader. RA private keys are

deactivated upon system log-off. System administrators and end-user subscriber’s private keys may be

deactivated after each operation, upon logging off their system or upon removal of their token or card

from the authentication mechanism. In all cases end-user subscribers have an obligation to protect their

private key(s) in accordance with sections “6.4.2 Activation Data Protection” and the subscriber

obligations in section "1.3.3 Subscribers (End Entities)"

6.2.10 Method of Destroying Private Key

At the conclusion of the TSPs’ CA’s operational lifetime, one or more copies of the CA private key are

archived in accordance with section "6.2.5 Private Key Archival". Remaining copies of the CA private key

are securely destroyed. In addition, archived CA private keys are securely destroyed at the conclusion of

their archive periods.

6.2.11 Cryptographic Module Rating

Cryptographic modules used by the TSP meet the requirements specified in section "6.2.1 Cryptographic

Module Standards and Controls".


Commfides Norge AS

6.3 Other Aspects of Key Pair Management

The TSP uses the CA private signing keys appropriately and does not use them beyond the end of their life

cycle. In particular:

Certificate generation:

a) CA signing key(s) used for generating certificates and/or issuing revocation status information, are

not used for any other purpose.

b) The certificate signing keys are only used within physically secure premises.

c) The use of the CA's private key are compatible with the hash algorithm, the signature algorithm

and signature key length used for generating certificates, in line with current practice.

d) All copies of the CA private signing keys are destroyed at the end of their life cycle.

6.3.1 Public Key Archival

The TSP CA, RA and end-user subscriber certificates are backed up and archived as part of the TSP routine

backup procedures.

6.3.2 Certificate Operational Periods and Key Pair Usage Periods

The operational period of a certificate ends upon its expiration or revocation. The operational period for

key pairs is the same as the operational period for the associated certificates, all use of the key pair shall

cease after their usage period have expired, except private keys may continue to be used for decryption

and public keys may continue to be used for signature verification.

Certificates issued by CAs to end-user subscribers may have operational periods from 1 to 5 years.

The root “CPN RootCA SHA256 Class 3” and its subordinate CA certificates "CPN Person High SHA256

CLASS 3" and "CPN Enterprise SHA256 CLASS 3" all expires on 31.12.2024.

End-user certificates shall have an expiration date before their signing subordinate certificate. Meaning

an end-user certificate with 3 years operational period, shall not be issued after 30.12.2021.


Commfides Norge AS

6.4 Activation Data


The installation and recovery of the CA's key pairs in a secure cryptographic device require

simultaneous control of at least two trusted employees.


[QCP-l-qscd]

Secure cryptographic device (including smartcard) deactivation and reactivation are done

securely.

Where the secure cryptographic device (including smartcard) has associated user activation data

(like PIN code), the activation data is securely prepared and distributed separately from the secure

cryptographic device. Separation is allowed to be achieved by ensuring distribution of activation

data and delivery of secure user device at different times, or via a different channel. See also CPS

section “4.3 Certificate Issuance”.

6.4.1 Activation Data Generation and Installation

The TSP CA Private Key generation is carried out according to the TSP Key Ceremony by trusted personnel

in trusted roles. The CA private key is randomly generated and stored using a secure encryption device.

6.4.2 Activation Data Protection

The TSP CA private key activation data is protected in a physically secured environment under dual

control with at least two trusted personnel in trusted roles (see section “5.2.1 Trusted Roles”)

6.4.3 Other Aspects of Activation Data

No stipulation.


Commfides Norge AS

6.5 Computer Security Controls

The TSP's system access is limited to authorized individuals. In particular:

a) Controls protect the TSP's internal network domains from unauthorized access including access by

subscribers and third parties. Firewalls are also configured to prevent all protocols and accesses

not required for the operation of the TSP.

b) Sensitive data is protected against being revealed through re-used storage objects being

accessible to unauthorized users.


c) Local network components are kept in a physically and logically secure environment and their

configurations are periodically checked for compliance with the requirements specified by the

TSP.

d) The TSP enforce multi-factor authentication for all accounts capable of directly causing certificate

issuance.

Dissemination:

e) Dissemination application enforces access control on attempts to add or delete certificates and

modify other associated information.

Certificate Revocation status:

f) Revocation status application enforces access control on attempts to modify revocation status

information.

Certificate generation and revocation management:

Continuous monitoring and alarm facilities are provided to enable the TSP to detect, register and react in

a timely manner upon any unauthorized and/or irregular attempts to access its resources.

6.5.1 Specific Computer Security Technical Requirements

See section “6.5 Computer Security Controls” above.

6.5.2 Computer Security Rating

See section “6.5 Computer Security Controls” above.


Commfides Norge AS

6.6 Life Cycle Technical Controls

Operation security

The TSP uses trustworthy systems and products that are protected against modification and ensures the

technical security and reliability of the processes supported by them. In particular:

a) An analysis of security requirements are carried out at the design and requirements specification

stage of any systems development project undertaken by the TSP or on behalf of the TSP to

ensure that security is built into IT systems. This is according to the TSP’s internal information

security policy.

b) Change control procedures are applied for releases, modifications and emergency software fixes

of any operational software and changes to the configuration which applies the TSP's security

policy. The procedure includes documentation of the changes. This is according to the TSP’s

change procedure.

c) The integrity of TSP systems and information are protected against viruses, malicious and

unauthorized software. This is according to the TSP’s internal information security policy.

d) Media used within the TSP systems are securely handled to protect media from damage, theft,

unauthorized access and obsolescence. This is according to the TSP’s internal policy and

procedure.

e) Media management procedures are protected against obsolescence and deterioration of media

within the period of time that records are required to be retained.

f) Procedures are established and implemented for all trusted and administrative roles that impact

on the provision of services.

g) The TSP specifies and applies procedures for ensuring that:

i. Security patches are applied within a reasonable time after they come available;

ii. Security patches are not applied if they introduce additional vulnerabilities or instabilities

that outweigh the benefits of applying them; and

iii. The reasons for not applying any security patches are documented.

Capacity demands are monitored and projections of future capacity requirements are made to ensure

that adequate processing power and storage are available.

6.6.1 System Development Controls

See section “6.6 Life Cycle Technical Controls” above.

6.6.2 Security Management Controls



Commfides Norge AS

6.6.3 Life Cycle Security Controls



Commfides Norge AS

6.7 Network Security Controls

The TSP protects its network and systems from attack. In particular:

a) The TSP segments its systems into networks or zones based on risk assessment considering

functional, logical, and physical (including location) relationship between trustworthy systems

and services. The TSP applies the same security controls to all systems co-located in the same

zone.

b) The TSP restricts access and communications between zones to those necessary for the

operation of the TSP. Not needed connections and services are forbidden or deactivated. The

established rule set is reviewed on a regular basis.

c) The TSP keeps all systems that are critical to the TSP operation in one or more secured zone(s)

d) Dedicated network for administration of IT systems and TSP operational network are

separated. The production systems for the TSP services are separated from systems used in

development and testing.

e) Communication between distinct trustworthy systems are only established through trusted

channels that are logically distinct from other communication channels and provide assured

identification of its end points and protection of the channel data from modification or

disclosure.

f) The TSP undergoes a regular vulnerability scan on public and private IP addresses identified by

the TSP and records evidence that each vulnerability scan was performed by a person or entity

with the skills, tools, proficiency, code of ethics, and independence necessary to provide a

reliable report.

g) The TSP undergoes a penetration test on the TSP's systems at set up and after infrastructure

or application upgrades or modifications that the TSP determines are significant. The TSP

records evidence that each penetration test was performed by a person or entity with the

skills, tools, proficiency, code of ethics, and independence necessary to provide a reliable

report.

h) The TSP maintains and protects all CA systems in at least a secure zone and implements and

configures a security procedure that protects systems and communications between systems

inside secure zones and high security zones.

i) The TSP configures all CA systems by removing or disabling all accounts, applications, services,

protocols, and ports that are not used in the CA's operations.

j) The TSP grants access to secure zones and high security zones to only trusted roles. According

to section “5.2.1 Trusted Roles” and according to internal procedures and policies.

k) The Root CA system is in high security zone.

6.8 Time-Stamping

No stipulation.


Commfides Norge AS

7. CERTIFICATE, CRL, AND OCSP PROFILES

All the TSP’s digital certificates conform to RFC 5280 and utilize the “ITU-T X.509 version 3 Digital

certificate standards”.


The end-user certificates are issued according to the assurance level "High" as defined in Regulation (EU)

No 910/2014 [1].


The end-user certificates are issued according to the assurance level "Substantial" as defined in

Regulation (EU) No 910/2014 [1].

7.1 Certificate Profile

The certificates shall be issued according to the relevant certificate profile as in section “7.1.6 Certificate

Policy Object Identifier”. All certificate profiles are described in APPENDIX 3

7.1.1 Version Number(s)

All the TSP’s certificates are version 3

7.1.2 Certificate Extensions

All certificate extensions are described in APPENDIX 3

7.1.3 Algorithm Object Identifiers

The attribute “Signature algorithm” identifies the algorithms (cryptographic mechanisms) used. The TSP

uses an applicable combination of asymmetrical and hash algorithms: sha256withRSA.

7.1.4 Name Forms

The TSP populates CTE certificates with an issuer and subject distinguished name in accordance with

section “3.1.1 Types of Names”. In addition, the TSP includes within end-user subscriber certificates two

additional organizational unit fields that indicate the certificate type, and name of the CA that generated

it. Exceptions to the foregoing requirement are permitted only when space, formatting, or

interoperability limitations within certificates make such an organizational unit impossible to use in

conjunction with the application for which the certificates are intended.

7.1.5 Name Constraints

No stipulation.


Commfides Norge AS


Commfides Norge AS

7.1.6 Certificate Policy Object Identifier

This CP/CPS covers the following OID’s; 0) Certificate Policy

Identifier: Certificate Policy ID CA Profile Name


2.16.578.1.29.13.10.X.X 0.4.0.2042.1.2

2)

ETSI EN 319 411-1 NCP+ 3)

Enterprise_Hard_Sign_13.10

2.16.578.1.29.13.11.X.X 0.4.0.194112.1.3

1)

ETSI EN 319 411-2 [QCP-l-qscd] 4)

Enterprise_Hard_Auth_13.11

2.16.578.1.29.13.12.X.X 0.4.0.2042.1.2

2)

ETSI EN 319 411-1 NCP+ 5)

Enterprise_Hard_Enc_13.12


2.16.578.1.29.13.20.X.X 0.4.0.2042.1.1

2a)

ETSI EN 319 411-1 NCP 3)

Enterprise_Soft_Sign_13.20

2.16.578.1.29.13.21.X.X 0.4.0.194112.1.1

1a)

ETSI EN 319 411-2 [QCP-l] )4)

Enterprise_Soft_Auth_13.21

2.16.578.1.29.13.22.X.X 0.4.0.2042.1.1

2a)

ETSI EN 319 411-1 NCP 5)

Enterprise_Soft_Enc_13.22


2.16.578.1.29.13.30.X.X 0.4.0.2042.1.3

2b)

ETSI EN 319 411-1 LCP 3)


2.16.578.1.29.13.31.X.X 0.4.0.2042.1.3

2b)

ETSI EN 319 411-1 LCP )4)


2.16.578.1.29.13.32.X.X 0.4.0.2042.1.3

2b)

ETSI EN 319 411-1 LCP 5)


All the certificates are issued to legal person (not to natural person). The certificates are signed by

subordinate CA “CPN Enterprise SHA256 CLASS 3”

Certificate Policy Identifier: 0) For certificate Policy Identifier OID:

Common for all the identified certificate Policy Identifier is the first five numbers; 2.16.578.1.29

OBJECT IDENTIFIER::= {joint-iso-itu-t(2) country(16) Norway(578) organization(1) CN (29)

The following four numbers from six to nine is built like this:

Six; 13 = Issued to legal person

Seven; 10, 20 and 30 = Key usage is Non-Repudiation (40), 11, 21 and 31 = Digital signature (80), 12, 22

and 32 = Key Encipherment, Data Encipherment, Key Agreement (38),

Eight and Nine; Version number. The current version numbers are always presented at the first page of

this CP/CPS.

Certificate Policy ID 1) 0.4.0.194112.1.3; itu-t(0) identified-organization(4) etsi(0) qualified-certificate-policies(194112)

policy-identifiers(1) qcp-legal-qscd (3). Policy for EU qualified certificates issued to legal persons offering

the level of quality defined in Regulation (EU) N° 910/2014 [i.1] for EU qualified certificates and requiring

the use of a Qualified Signature Creation Device (QSCD).

1a) 0.4.0.194112.1.1; itu-t(0) identified-organization(4) etsi(0) qualified-certificate-policies(194112)

policy-identifiers(1) qcp-legal (1). Policy for EU qualified certificates issued to legal persons (QCP-l)

offering the level of quality defined in Regulation (EU) N° 910/2014 [i.1] for EU qualified certificates.


Commfides Norge AS

2) 0.4.0.2042.1.2; itu-t(0) identified-organization(4) etsi(0) other-certificate-policies(2042) policy-

identifiers(1) ncpplus (2) 2a) 0.4.0.2042.1.1; itu-t(0) identified-organization(4) etsi(0) other-certificate-policies(2042) policy-

identifiers(1) ncp (1) 2b) 0.4.0.2042.1.3; itu-t(0) identified-organization(4) etsi(0) other-certificate-policies(2042) policy-

identifiers(1) lcp (3) 3) Key usage for certificate is; Non-Repudiation (40) 4) Key usage for certificate is; Digital signature (80) 5) Key usage for certificate is; Key Encipherment, Data Encipherment, Key Agreement (38)

The subordinate CA certificates;

“CPN Enterprise SHA256 CLASS 3” has the following certificate Policy Policy Identifier included;

2.16.578.1.29.13.1.1.0,

These identified certificate Policy Identifier means that the subordinate CA certificates are valid for

signing certificates with all certificate policy identifiers.

7.1.7 Usage of Policy Constraints Extension

No stipulation.

7.1.8 Policy Qualifiers Syntax and Semantics

This CP/CPS includes numerous certificate policies and certificate practice statement as listed in section

“7.1.6 Certificate Policy Object Identifier” meaning that certificates with a different CP/CPS – OID is listed

within the same CP/CPS document. Both the CP and CPS are handled in the same document.

If not specified within a section in the document, each text/tables apply for all the CP/CPS –OIDs. The text

may also be conditional, meaning it only applies to one or more of the indicated CP/CPS-OIDs. This is

marked by [] and inside indicating which CP/CPS-OID it applies to.

A section starting with this “[CPN legal person NCP+]” indicates this is only applicable for the certificates

with the OIDs: 2.16.578.1.29.13.10.X.X, 2.16.578.1.29.13.11.X.X and 2.16.578.1.29.13.12.X.X

A section starting with “[CPN legal person NCP]” indicates this part is only applicable for the certificates


A section starting with “[CPN legal person LCP]” indicates this part is only applicable for the certificates


A section starting with “[NCP+ Encryption]” indicates this part is only applicable for the certificates with

the OID 2.16.578.1.29.13.12.X.X


Commfides Norge AS

A section starting with “[NCP Encryption]” indicates this part is only applicable for the certificates with the

2.16.578.1.29.13.22.X.X (See section “7.1.6 Certificate Policy Object Identifier”)

A section starting with “[LCP Encryption]” indicates this part is only applicable for the certificates with the

2.16.578.1.29.13.32.X.X (See section “7.1.6 Certificate Policy Object Identifier”)

If there are changes in the CP/CPS-document, which are limited for a specific CP/CPS-OID and not the

other ones. There will only be a new version of this CP/CPS-OID and not the other CP/CPS-OIDs

(regardless they are in the same document).

7.1.9 Processing Semantics for the Critical Certificate Policies Extension

No stipulation.


Commfides Norge AS

7.2 CRL Profile

The TSP issues CRLs that conform to RFC 5280. At a minimum, the TSP’s CRLs contain the basic fields and

contents specified in Table 10 below:

Field Value or Value constraint

Version 2

Signature algorithm

Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA

Algorithm Parameters: 05 00

Issuer C = NO

O = Commfides Norge AS - 988 312 495

OU = Commfides Trust Environment (c) 2011 Commfides Norge AS

CN = CPN Person High SHA256 CLASS 3

Effective date

Issue date of the CRL. The TSP’s CRLs are effective upon issuance.

Next update Date by which the next CRL will be issued. The next update date for the TSP’s CRLs is set as follows: 120 hours from the effective date for all the TSP’s CAs. CRL issuance frequency is in accordance with the requirements of section “4.9.7 CRL Issuance Frequency (if applicable)”

Revoked certificates

Listing of revoked certificates, including the serial number of the revoked certificate and the revocation date.

Table 10 – CRL Profile Basic Fields

CRLs are signed with keys crlSignKey located at the CA server. All CRLs are stored in CA database and

backed up for historic verification.


See section “7.2 CRL Profile”

7.2.2 CRL and CRL Entry Extensions

Field Value or Value constraint

CRL

Extensions:

3

2.5.29.35: Flags = 0, Length = 18

Authority Key Identifier

KeyID=92 cd 80 1c 1e c1 b9 79 3c b5 a8 83 92 c8 5c 88 8d 48 ce b9

2.5.29.20: Flags = 0, Length = 4

CRL Number

CRL Number=incremental


Commfides Norge AS

Signature

Algorithm:

Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA

Algorithm Parameters:

05 00

Signature: UnusedBits=0

0000 2d ee 7b 9a 04 cb 96 b4 48 8d 5d 7b 6d d9 d5 9e

0010 76 f3 3d 36 97 b1 bf 2a 93 67 e2 c9 bd 35 52 84

0020 6a ec b2 d2 77 35 f8 51 02 7a 93 19 bb 8c 2b e2

0030 93 de d4 e7 4d f7 8d e0 61 0f bd 92 31 db 48 b8

0040 12 d7 8b 37 f5 b9 13 15 c3 22 c8 dc 16 c8 d1 2e

0050 c2 48 9f b0 51 0a a2 f0 9d 78 40 27 73 72 13 16

0060 af 90 8e e0 24 43 87 cb 53 c0 b4 c9 14 ea 63 4a

0070 50 18 e7 e6 eb 4b 46 ef c4 fe 4f 2c a9 47 4c 4c

0080 9b 8d 07 fa be a9 13 ca 72 d0 02 9f 19 aa f7 3f

0090 b7 91 67 c0 6d 39 d8 8a 0a 3d c6 db e2 25 69 1b

00a0 5c 1c 5b 90 d8 7f 17 d6 c5 ce 9f d1 f5 03 6a 9f

00b0 cf 45 91 eb 95 1d a4 7f 1c e5 5b 25 56 47 ab 6e

00c0 0a 4f 63 d4 70 f9 5b 67 38 b7 ba b7 35 9f f8 96

00d0 8c 60 1f 17 ff f6 95 66 e2 01 ab 3d 84 c7 c6 07

00e0 c8 7a c3 75 5b 31 5b 76 80 9b c8 7a 7d 3e dc 81

00f0 cb 2b aa 6c b2 94 a8 d6 c3 e0 b1 2e 24 3c 06 30

certificate

Extensions

1

2.5.29.21: Flags = 0, Length = 3

CRL Reason Code

7.3 OCSP Profile


Version 1. See “Appendix 3, Commfides Certificate Profiles” under “OCSP profile”

7.3.2 OCSP Extensions

See “Appendix 3, Commfides Certificate Profiles” under “OCSP profile”


Commfides Norge AS

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

To ensure that the requirements of this CP /CPS are being implemented and enforced and to be act upon

according to requirement and recommendations stated in REGULATION (EU) No 910/2014 [1] and ISO

27001 - ISO/IEC 27001 [6] the TSP is having conformity assessment both internal and external. These are

be held on a regular basis and may be held when requested both from the organization it selves or from

authorized external parties.

The conformity assessment is held by a conformity assessment body approved by the supervisory body in

the relevant EU/EEA member state as stated in REGULATION (EU) No 910/2014 [2]. The Norwegian Nkom

is the conformity assessment body for the TSP.

The TSP has a defined review process for this CP/CPS which including responsibilities for maintaining the

TSP practice statement.

The procedure is named “CN-GPR-44_External and Internal Audits Procedure” and is available for internal

use and for authorized external parties

8.1 Frequency or Circumstances of Assessment

The TSP are audited at least every 24 months by a conformity assessment body. The purpose of the audit

is to confirm that the TSP as a qualified trust service provider and the qualified trust services provided by

the TSP fulfil the requirements laid down in REGULATION (EU) No 910/2014 [2]. The TSP submits the

resulting conformity assessment report to the supervisory body within the period of three working days

after receiving it.

In accordance with REGULATION (EU) No 910/2014 [2] article 20, the TSP accept the supervisory body (or

a conformity body upon the supervisory request) upon request to perform audits at all time, to confirm

the TSP fulfil its scope to be according to the requirements laid down in REGULATION (EU) No 910/2014

[2]

Where personal data protection rules appear to have been breached, the supervisory body informs the

data protection authorities of the results of its audits.

8.2 Identity/Qualifications of Assessor

No stipulation.

8.3 Assessor's Relationship to Assessed Entity

The TSP and the conformity assessment body are independent of each other.


Commfides Norge AS

8.4 Topics Covered by Assessment

Within the scope of the TSP’s CP/CPS the REGULATION (EU) No 910/2014 [1], ISO 27001 - ISO/IEC 27001

[6] and ETSI EN 319 411-1 [3] and ETSI EN 319 411-2 [4] is covered by assessment.

8.5 Actions Taken as a Result of Deficiency

Finding of deficiencies in assessment are treated promptly and according to the TSP internal procedure

for internal and external audits.

8.6 Communication of Results

The supervisory body Nkom is entitled to see the results of the assessment from the conformity

Assessment Body. The TSP sends the result of the assessment to the supervisory body no later than three

days after receiving the result from the conformity assessment body.


Commfides Norge AS

9. OTHER BUSINESS AND LEGAL MATTERS

9.1 Fees

The fees for services provided by the TSP in respect to the TSPs’ certificates are stated in the agreements

between the TSP and each individual customer and some fees may be published on the TSP web pages at

www.commfides.com.

9.1.1 Certificate Issuance or Renewal Fees

See above section at “9.1 Fees”

9.1.2 Certificate Access Fees


9.1.3 Revocation or Status Information Access Fees


9.1.4 Fees for Other Services


9.1.5 Refund Policy

Purchase of the TSP certificates may either be consumer purchases or commercial purchases. Consumer

purchases are certificates sold to a private person, commercial purchases is sale to a legal business.

For consumer purchase the agreement are subject to the rules for consumer purchases «Lov om

forbrukerkjøp (forbrukerkjøpsloven)” If the customer cancels the purchase after the certificate is sent

from the TSP’s distribution, the customer are charged a fee for the distribution of the certificate

according to the current price list on https://www.commfides.com

For all other purchases the refund policy, if any, is stated in agreement between the TSP and the

customer.

http://www.commfides.com/

https://www.commfides.com/


Commfides Norge AS

9.2 Financial Responsibility

The TSP is maintained with sufficient financial resources and liability insurance, in accordance with

national law, to cover liabilities arising from its operations.

The TSP is liable for damage caused intentionally or negligently to any natural or legal person due to a

failure to comply with the obligations in this CP/CPS. This liability for damage is limited up to maximum

10000,- NOK, and applies only to direct loss for the customer not for indirect loss caused by the incident.

The intention or negligence of the TSP is presumed unless that the TSP proves that the damage occurred

without the intention or negligence of the TSP.

The TSP inform their customers in advance of the limitations (see CA, RA, subscriber and relying parties

obligations in section “1.3 PKI Participants” and section “9.17 Other Provisions” under “Terms and

Conditions”) on the use of the services the TSP provide and those limitations are made recognisable to

third parties, the TSP is not liable for damages arising from the use of services exceeding the indicated

limitations.

See section “9.6 Representations and Warranties” regarding warranties.

9.2.1 Insurance Coverage

See section “9.2 Financial Responsibility” above.

9.2.2 Other Assets


9.2.3 Insurance or Warranty Coverage for End-Entities



Commfides Norge AS

9.3 Confidentiality of Business Information

9.3.1 Scope of Confidential Information

No stipulation

9.3.2 Information Not Within the Scope of Confidential Information

No stipulation

9.3.3 Responsibility to Protect Confidential Information

No stipulation


Commfides Norge AS

9.4 Privacy of Personal Information

The TSP is undertaking technical and organizational measures against unauthorized and unlawful

processing of personal data and against accidental loss and destruction of, and damage to, personal data.

The confidentiality and integrity of registration data are protected, especially when exchanged with the

subscriber/subject or between distributed TSP system components. All exchanging of electronic

registration data is encrypted.

Records are securely retained according to sections "5.4 Audit Logging Procedures" and

"5.5 Records Archival".

To protect personal data, measures are implemented:

Access to personal data are protected enforcing use of password or multi-factor authentication

and is conducted according to procedural and personnel control (see sections “5.2 Procedural

Controls” and “5.3 Personnel Controls”);

Recording user consent (section “4.4 Certificate Acceptance”); The TSP records the signed

agreement with the subscriber

Confidentiality of records (section "4.2 Certificate Application Processing"; when external

registration service providers are used registration data shall be exchanged securely and only with

recognized registration service providers, whose identity is authenticated and in accordance with

section "5.4 Audit Logging Procedures"; The TSP is maintaining the privacy of subject

information.));

Secure registration (see section "3.2 Initial Identity Validation");

9.4.1 Privacy Plan

See section “9.4 Privacy of Personal Information” above.

9.4.2 Information Treated as Private

The following information/records are kept confidential and private (treated as private):

CA application records, whether approved or disapproved;

Certificate application records;

Transactional records and the audit trail of transactions;

Audit reports created by the TSP, another TSP member or their respective auditors (whether

internal or public) with the exceptions of section “8.6 Communication of Results”;

Contingency planning and disaster recovery plans; and


Commfides Norge AS

Security measures controlling the operations of the TSPs’ hardware and software and the

administration of certificate services and designated enrollment services.

9.4.3 Information not Deemed Private

The following information/records are not considered confidential or private:

Certificates and their belonging public keys. Certificates and their belonging public key is public

available at the TSP’s LDAP service.

Certificate status. A certificate’s status is public available at the TSP’s CRL and OCSP service.

9.4.4 Responsibility to Protect Private Information

See section “9.4 Privacy of Personal Information” above.

9.4.5 Notice and Consent to use Private Information

The TSP notices the subject/subscriber regarding the use of private information regarding the

subject/subscriber in subscriber/subject agreement/ PDS. The TSP is obligated to inform the

subscriber/subject regarding the use of private information and the subscriber/subject are obligated to

accept this usage in order to receive its certificate. See section “4.4 Certificate Acceptance” for details

regarding certificate acceptance.

9.4.6 Disclosure Pursuant to Judicial or Administrative Process

The TSP is entitled to disclose confidential/private information if the TSP believes that disclosure is

necessary in response to judicial, administrative, or other legal process during the discovery process in a

civil or administrative action, such as subpoenas, interrogatories, requests for admission, and requests for

production of documents. This section is subject to applicable privacy laws.

9.4.7 Other Information Disclosure Circumstances

See section “9.4.6 Disclosure Pursuant to Judicial or Administrative Process” above.


Commfides Norge AS

9.5 Intellectual Property Rights

Intellectual property rights in relation to subscribers/subject and relying Parties:

Property rights in certificates and revocation Information:

The TSP retains all intellectual property rights in and to the certificates and revocation information that

they issue. CTE members and customers grant permission to reproduce and distribute certificates on a

nonexclusive royalty-free basis, provided that they are reproduced in full and that use of certificates is

subject to the relying party agreement referenced in the certificate. CTE members and customers shall

grant permission to use revocation information to perform relying party functions subject to the

applicable CRL usage agreement, relying party agreement, or any other applicable agreements.

Property rights in the CP:

CTE Participants acknowledge that the TSP retains all Intellectual property rights in and to the CPS.

Property rights in names:

A certificate applicant retains all rights it has (if any) in any trademark, service mark, or trade name

contained in any certificate application and distinguished name within any certificate issued to such

certificate applicant.

Property rights in keys and key material:

Key pairs corresponding to certificates of CAs and end-user subscribers are the property of the CAs and

end-user subscribers that are the respective subjects of these certificates. Without limiting the generality

of the foregoing, CTE member’s public keys and the certificates containing they are the property of the

respective CTE Member.


Commfides Norge AS

9.6 Representations and Warranties

The TSP retains the overall responsibility for conformance with the procedures prescribed in this CP and

CPS and within the scope of its information security policy, including the functionality that is undertaken

by outsourcers. The TSP provides all its certification services consistent with its CPS.

The outsourcers and their liability are defined by the TSP within its information security management

system. The TSP is responsible for outsources implementing necessary control for the TSP and its services

to comply with this CP and CPS. The TSP is responsible for outsourcers being bound to implement their

control using appropriate agreements.

All obligations specified for NCP in ETSI EN 319 411-1 [3] applies to the TSP when the TSP's terms and

conditions do not require a secure cryptographic device, If a secure cryptographic device is required the

NCP+ obligation applies.

9.6.1 CA Representations and Warranties

See section “1.3.1 Certification Authorities” for CA obligation.

9.6.2 RA Representations and Warranties

See section “1.3.2 Registration Authorities” for RA obligation.

9.6.3 Subscriber Representations and Warranties

See subscriber obligation in section “1.3.3 Subscribers (End Entities)” and “Indemnification by

subscribers/subjects” in section “9.9 Indemnities”

9.6.4 Relying Party Representations and Warranties

See relying party obligation in section “1.3.4 Relying Parties” and "Indemnification by Relying Parties" in

section “9.9 Indemnities”

9.6.5 Representations and Warranties of other Participants

No stipulation.


Commfides Norge AS

9.7 Disclaimers of Warranties

See section "9.6 Representations and Warranties"

9.8 Limitations of Liability

For end-user subscriber certificates signed with the “CPN Person High SHA256 CLASS 3” or “CPN

Enterprise SHA256 CLASS 3” the TSP pursues the liability for certificates issued under this policy as

specified in Regulation (EU) No 910/2014 [1], ETSI EN 319 411-1 [3] and ETSI EN 319 411-2 [4]

The TSP liability:

Limited up to NOK 10000,- (See CPS section “9.2 Financial Responsibility” for details)

Certificate owner and relying Parties may choose to enhance this limited liability by buying a higher

coverage.

Limitations on liability are covered in the terms and conditions as per clause "9.17 Other Provisions"

section "Terms and conditions".

9.9 Indemnities

Indemnification by subscribers/subjects

To the extent permitted by applicable law, TSP’s subscriber/subjects agreement requires, and other

subscriber/subjects agreements shall require, subscribers/subjects to indemnify the TSP, its licensees and

any RAs for:

Falsehood or misrepresentation of fact by the subscriber/subject on the subscriber’s/subjects

certificate application;

Failure by the subscriber/subject to disclose a material fact on the certificate application, if the

misrepresentation or omission was made negligently or with intent to deceive any party;

The subscriber’s/subjects failure to protect the subscriber’s/subjects private key, to use a

trustworthy system, or to otherwise take the precautions necessary to prevent the compromise,

loss, disclosure, modification, or unauthorized use of the subscriber’s private key; or

The subscriber’s/subjects use of a name (including without limitation within a common name,

domain name, or e-mail address) that infringes upon the intellectual property rights of a third

party.

Indemnification by relying Parties

To the extent permitted by applicable law, the TSP’s relying party agreements and other relying party

agreements require relying parties to indemnify the TSP and its licensees and any RAs for:

The relying party’s failure to perform the obligations of a relying party (see section “1.3.4 Relying


Commfides Norge AS

Parties”);

The relying party’s reliance on a certificate that is not reasonable under the circumstances; or

The relying party’s failure to check the status of such certificate to determine if the certificate is

expired or revoked.

9.10 Term and Termination

9.10.1 Term

See section “9.11 Individual Notices and Communications with Participants”.

9.10.2 Termination


9.10.3 Effect of Termination and Survival


9.11 Individual Notices and Communications with Participants

To the extent permitted by applicable law, The TSP’s subscriber/subject agreements and relying party

agreements contain, and other subscriber agreements and relying party agreements shall contain,

severability, survival, merger, and notice clauses. A severability clause in an agreement prevents any

determination of the invalidity or unenforceability of a clause in the agreement from impairing the

remainder of the agreement. A survival clause specifies the provisions of an agreement that continue in

effect despite the termination or expiration of the agreement. A merger clause states that all

understandings concerning the subject matter of an agreement are incorporated in the agreement. A

notice clause in an agreement sets forth how the parties are to provide notices to each other.

9.12 Amendments

The TSP notify notice of changes it intends to make in its practice statement and, following approval as in

section “1.5.4 CPS approval procedures” and make the revised TSP practice statement immediately

available. The notify notice of change is at least given to the supervisory body and is given prior to the

intended change.


Commfides Norge AS

9.12.1 Procedure for Amendment

Any changes to this CP/CPS must be approved by the Commfides Certificate Advisory Board according to

section “1.5.4 CPS approval procedures”. If a change in the CP/CPS results in a new OID version, new

certificates issued will have this new OID version referenced to.

Updates supersede any designated or conflicting provisions of the referenced version of the CP/CPS.

9.12.2 Notification Mechanism and Period

The TSP notifies its supervisory body and the conformity assessment body upon intended changes to its

CP/CPS and if applicable affected parties. The TSP reserves the right to amend this CP/CPS without

notification to end-users.

By using other identification methods recognised at national level which provide equivalent assurance in

terms of reliability to physical presence. The equivalent assurance is required to be confirmed by the

conformity assessment body.

9.12.3 Circumstances Under Which OID Must be Changed

In general, changes to this CP/CPS result in a new OID version for the effected certificate. (See section

“7.1.8 Policy Qualifiers Syntax and Semantics” for the logic in changing the CP OIDs). If changes not

materially reduce the assurance that a CP/CPS or its implementation provides, and are judged by the

Commfides Certificate Advisory Board to have an insignificant effect on the acceptability of certificates,

then change in the CP OID are not required. Changes in the CP/CPS that materially change the

acceptability of certificates for one or more specific purposes requires corresponding changes to the CP

OID.

9.13 Dispute Resolution Provisions

The TSP have policies and procedures for the resolution of complaints and disputes received from

customers or other relying parties about the provisioning of the services or any other related matters

Procedure for the resolution of complaints and disputes received from customers or other relying parties

about the provisioning of the services or any other related matters:

In order to have a complaint/dispute processed by the TSP the customer/subscriber are obligated to;

In cases regarding certificates issued to legal persons whereas the certificate has been sold through one

of the TSP’s distributors, the complaint/ dispute shall be submitted by this distributor.

The complaint/ dispute shall clearly identify involved services/certificate(s), time of incident, grounds for

complaints/dispute. The complaint/ dispute shall be sent to [email protected]



Commfides Norge AS

The TSP is obligated to;

Confirm the receipt of the complaints/dispute.

Process the complaint/dispute and within reasonable time respond with the outcome of the process or

invite to further negotiation.

Disputes between the TSP and its customers are aimed to be solved in amiability negotiations between

the parties. Disputes, if required, are to be solved in the court of “Asker og Bærum Tingrett”. The

relationship between the customer and the TSP is regulated by Norwegian laws.

9.14 Governing Law

Subject to any limits appearing in applicable law, the laws of the Kingdom of Norway.

9.15 Compliance with Applicable Law

The TSP operates in a legal and trustworthy manner and provided evidence on how it meets the

applicable requirements is documented within the scope of the TSP’s ISMS (Information Security

Management System).

9.16 Miscellaneous Provisions

9.16.1 Entire Agreement

Applicable circumstances regarding entire agreement is stated in agreements between the TSP and its

legal counterpart.

9.16.2 Assignment

Applicable circumstances regarding assignment are stated in agreements between the TSP and its legal

counterpart.

9.16.3 Severability

Applicable circumstances regarding severability are stated in agreements between the TSP and its legal

counterpart.


Commfides Norge AS

9.16.4 Enforcement (Attorneys' Fees and Waiver of Rights)

Applicable circumstances regarding enforcement (attorneys’ fees and waiver rights) are stated in

agreements between the TSP and its legal counterpart.

9.16.5 Force Majeure

Applicable circumstances regarding force majeure are stated in agreements between the TSP and its legal

counterpart.


Commfides Norge AS

9.17 Other Provisions

The Terms and conditions are made available to subscribers and relying parties by the “Commfides-PDS-

for-Certificates-and-EU-Qualified-Certificates-Legal-Person-Central” For the qualified certificates these

terms and conditions are linked directly in the certificates. These PDS are available at links specified in

“Appendix 3, Commfides Certificate Profiles” in the “PdsLocation” field.

Organizational

TSP Practice statement for maintaining a reliable organization:

Trust service practices under which the TSP operates are non-discriminatory.

The TSP makes its services accessible to all applicants whose activities fall within its declared field

of operation and that agree to abide by their obligations as specified in the TSP terms and

conditions (/The PKI disclosure statement)

The TSP maintains financial resources sufficient to obtain appropriate liability insurance, in

accordance with national law, to cover liabilities arising from its operations and/or activities.

The TSP ensuring to have sufficient financial stability and resources required to operate in

conformity with this CP/CPS.

The TSP has policies and procedures for the resolution of complaints and disputes received from

customers or other relying parties about the provisioning of the services or any other related

matters, see CPS section “9.13 Dispute Resolution Provisions”

The TSP has documented agreements and contractual relationship in place where the provisioning

of services involves subcontracting, outsourcing or other third party arrangements. (See section

CPS “1.3.5 Other Participants” and “5.3.7 Independent Contractor Requirements”)

Certificate generation and revocation management:

The parts of the TSP concerned with certificate generation and revocation management are

ensured to be independent of other organizations for its decisions relating to the establishing,

provisioning and maintaining and suspending of services in conformance with the CP/CPS. Senior

executive, senior staff and staff in trusted roles, is free from commercial, financial and other

pressures which might adversely influence trust in the services it provides.

The parts of the TSP concerned with certificate generation and revocation management has a

documented structure which safeguards impartiality of operations (This is according to the TSP’s

internal certification services procedures)

Additional testing

The TSP provides the capability to allow third parties to check and test all the certificate types that

the TSP issues.


Commfides Norge AS

Test certificates clearly indicate that they are for testing purposes.

Disabilities

The TSP ensures it operates in a legal and trustworthy manner. In particular:

Trust services provided and end-user products used in the provision of those services are made accessible

for persons with disabilities.

Terms and conditions

TSP makes the terms and conditions (through its PKI disclosure statements) regarding its services

available to all subscribers and relying parties. These terms and conditions specify for each trust service

policy supported by the TSP the following:

a) The trust service policy being applied;

b) Any limitations on the use of the service;

c) The subscriber's obligations, if any;

d) Information for parties relying on the trust service;

e) The period of time during which TSP event logs are retained;

f) Limitations of liability;

g) Limitations on the use of the services provided including the limitation for damages arising from

the use of services exceeding such limitations;

h) The applicable legal system;

i) Procedures for complaints and dispute settlement;

j) Whether the TSP's trust service has been assessed to be conformant with the trust service policy,

and if so through which conformity assessment scheme;

k) The TSP contact information; and

l) Any undertaking regarding availability.

Subscribers and parties relying on the trust service are informed of precise terms and conditions,

including the items listed above, before entering into a contractual relationship. Terms and conditions are

made available through the PKI disclosure statement, linked directly in the issued end-user subscriber

certificates. The PKI disclosure statement is always available in English.


Commfides Norge AS

Appendix 1

Requirements hierarchy for Certificate Policy (CP).

The requirement in the CP at left side must be met in order the meet the additional requirements in the

CP at the right side. This is logic obtained from ETSI EN 319 411-1 [3] and ETSI EN 319 411-2 [4]. For the

CP/CPS in this document it is CP marked in bold and blue CP in the figure below that is the applicable for

the qualified certificates.

Q=Qualified

CP= Certificate Policy

NCP= Normalized certificate Policy

.-n = Natural Person

.-l = Legal Person

-qscd = Qualified electronic signature/Seal Creation Device

NCP+ If the TSP's implementation of this policy requires a secure cryptographic device, the

requirements for QCP-n include all the NCP+ requirements.

qscd: For EU qualified certificates and requiring the use of a Qualified Signature Creation Device

(QSCD). Such policy requires that the private key related to the certified public key resides in the

QSCD.

LCP= Lightweight Certificate Policy

LCP

QCP-n

QCP-l

QCP-n with device

QCP-l with device

QCP-n-qscd

QCP-l-qscd

EVCP QCP-w

NCPNCP+

LCP


Commfides Norge AS

Appendix 2

Overview and explanations for the services under the responsibility by the CA

• Registration service: verifies the identity and if applicable, any specific attributes of a subject. The results

of this service are passed to the certificate generation service.

This service includes proof of possession of non-CA generated subject private keys.

• Certificate generation service: creates and signs certificates based on the identity and other attributes

verified by the registration service. This can include key generation.

• Dissemination service: disseminates certificates to subjects, and if the subject consents, makes them

available to relying parties. This service also makes available the TSP's terms and conditions, and any

published policy and practice information, to subscribers and relying parties.

• Revocation management service: processes requests and reports relating to revocation to determine the

necessary action to be taken. The results of this service are distributed through the revocation status

service.

• Revocation status service: provides certificate revocation status information to relying parties.

• Subject device provision service: prepares, and provides or makes available secure cryptographic devices,

or other secure devices, to subjects.

Examples of this service are:

i) a service which generates the subject's key pair and distributes the private key to the subject;

ii) a service which prepares the subject's signature-creation module and enabling codes and distributes

the module to the registered subject.


Commfides Norge AS

Appendix 3, Commfides Certificate Profiles

This is the TSP’s (Commfides) certificate profiles for end-entity certificates signed by a subordinate CA,

which are signed by CA root certificate “CPN RootCA SHA256 Class 3”.

The certificates signed by the subordinate CA “CPN Enterprise SHA256 CLASS 3” these are issued to legal

persons.

This is the TSP’s (Commfides) certificate profiles for end-entity certificates signed by a subordinate CA,

which are signed by CA root certificate “CPN RootCA SHA256 Class 3”:

sha256 fingerprint for the “CPN RootCA SHA256 Class 3”:

e7 47 8c ea 79 5c b6 ab aa 1e 8b ae b5 08 a0 58 b4 8b 57 49

URL-download:

https://www.commfides.com/wp-content/uploads/2017/09/cpnrootcasha256class3.zip

The certificates are signed by the subordinate CA “CPN Enterprise SHA256 CLASS 3” these are issued to

legal persons.

sha256 fingerprint for the “CPN Person High SHA256 CLASS 3”:

dc 38 ac 1c b3 2a 5f 85 08 14 09 89 98 da d1 35 83 16 f4 86

URL-download:

https://www.commfides.com/wp-content/uploads/2017/09/cpnenterprisesha256class3.zip

This CP/CPS covers the following OID’s; 0) Certificate Policy

Identifier: Certificate Policy ID CA Profile Name


2.16.578.1.29.13.10.X.X 0.4.0.2042.1.2

2)

ETSI EN 319 411-1 NCP+ 3)

Enterprise_Hard_Sign_13.10

2.16.578.1.29.13.11.X.X 0.4.0.194112.1.3

1)

ETSI EN 319 411-2 [QCP-l-qscd] 4)

Enterprise_Hard_Auth_13.11

2.16.578.1.29.13.12.X.X 0.4.0.2042.1.2

2)

ETSI EN 319 411-1 NCP+ 5)

Enterprise_Hard_Enc_13.12


2.16.578.1.29.13.20.X.X 0.4.0.2042.1.1

2a)

ETSI EN 319 411-1 NCP 3)


2.16.578.1.29.13.21.X.X 0.4.0.194112.1.1

1a)

ETSI EN 319 411-2 [QCP-l] )4)


2.16.578.1.29.13.22.X.X 0.4.0.2042.1.1

2a)

ETSI EN 319 411-1 NCP 5)



2.16.578.1.29.13.30.X.X 0.4.0.2042.1.3 2b)

ETSI EN 319 411-1 LCP

3)


2.16.578.1.29.13.31.X.X 0.4.0.2042.1.3 2b)


)4)


2.16.578.1.29.13.32.X.X 0.4.0.2042.1.3 2b)


5)


All the certificates are issued to legal person (not to natural person). The certificates are signed by

subordinate CA “CPN Enterprise SHA256 CLASS 3” For details regarding 0) 1) 2ab) 3) 4) 5) See section “7.1.6

https://www.commfides.com/wp-content/uploads/2017/09/cpnrootcasha256class3.zip

https://www.commfides.com/wp-content/uploads/2017/09/cpnenterprisesha256class3.zip


Commfides Norge AS

Certificate Policy Object Identifier”

The end-user subscriber (subject) receives three certificates at once in its encryption device/ QSCD (or

other device if soft using NCP or LCP) as ordering certificate for legal person from the TSP. This is the

signing-, authentication- and encryption certificate. All three will be issued to the same legal person but

each certificate has different key usage.

I. CPN legal person NCP+

a. Enterprise_Hard_Sign_13.10

b. Enterprise_Hard_Auth_13.11

c. Enterprise_Hard_Enc_13.12

II. CPN legal person NCP

a. Enterprise_Soft_Sign_13.20

b. Enterprise_Soft_Auth_13.21

c. Enterprise_Soft_Enc_13.22

III. CPN legal person LCP




IV. Regarding QC statement

V. OCSP Profile


Commfides Norge AS


a. Enterprise_Hard_Sign_13.10

FIELD VALUE Critical MANDATORY

Issuer:

countryName (C) NO Y

organizationName(O) COMMFIDES NORGE AS - 988 312 495 Y

commonName (CN) CPN Enterprise SHA256 CLASS 3 Y

Subject DN:

countryName (C) <ISO 3166 Countrycode> Y

serialNumber <Business number as stated in Brønnøysundsregistrene or other applicable identification practices>

Y

commonName (CN) Subjectname <e.g. subscribername, systemname, applicationname, or Domain name owned by the Company>

Y

organizationName (O) <SubscriberName as stated in Brønnøysundsregistrene or other applicable identification practices> - <Business number as stated in Brønnøysundsregistrene or other applicable identification practices> The last <> is optional

Y

organizationIdentifier (2.5.4.97) NTRNO-<Business number as stated in Brønnøysundsregistrene or other applicable identification practices>

Y

OrganizationUnit(OU) <Subscriber Department> N

OrganizationUnit(OU) NBR=<The National Business Register used for validating the organizationName>

Y

OrganizationUnit(OU) NBR SN=<The National Business Register’s own Business number as stated in the National Business Register>

Y

OrganizationUnit(OU) Power of attorney Limitations. Individual option for each business to agree upon the limitations given to the certificate holder for the signing certificate. Given in the form of a transaction limitation or in a free form text.

N

locality (L) The employers visiting address as registered in Brønnøysundregistrene or other applicable identification practices.

Y

Subject Public Key Info 2048 Y

Key Usage nonRepudiation Y Y

Extended Key Usage Secure Email (1.3.6.1.5.5.7.3.4), Server Authentication (1.3.6.1.5.5.7.3.19)

N

Subject alternative name RFC822Name=<Subject emailaddress>

Y

CRL Distribution point http://crl1.commfides.com/CommfidesEnterprise-SHA256.crl http://crl2.commfides.com/CommfidesEnterprise-SHA256.crl

Y

Authority information access http://ocsp1.commfides.com/ocsp http://crl1.commfides.com/CommfidesEnterprise-SHA256.crt http://crl2.commfides.com/CommfidesEnterprise-SHA256.crt

Y

Certificate criteria (non critical x.509 extension)

Certificate Policy: Policyidentifier=2.16.578.1.29.13.10.X.X

OBJECT IDENTIFIER::= {joint-iso-itu-t(2) country(16) norway(578) organization(1) CN (29) CPN Enterprise SHA256 CLASS 3 (13) Key-Usage (10) version X.X}

Y

Subject information access <field not in use> N

Qualifed Certificate Statement <field not in use> N

Y

Validity (1-5) + 14 day Y

ETSI Policy OID 0.4.0.2042.1.2 Y

http://crl1.commfides.com/CommfidesEnterprise-SHA256.crl


http://ocsp1.commfides.com/ocsp

http://crl1.commfides.com/CommfidesEnterprise-SHA256.crt



Commfides Norge AS


b. Enterprise_Hard_Auth_13.11


Issuer:




Subject DN:



Y


Y


Y


Y



Y


Y


Y


Key Usage digitalSignature Y Y

Extended Key Usage Client Authentication (1.3.6.1.5.5.7.3.2), Secure Email (1.3.6.1.5.5.7.3.4), Server Authentication (1.3.6.1.5.5.7.3.19) Smart Card logon (1.3.6.1.4.1.311.20.2.2)

N

Subject alternative name RFC822Name=<Subject emailaddress> Other Name: Principal Name=<UPN>

Y


Y


Y


QCStatements

esi4-qcStatement-1 (EU-qualified certificate)

YES Y

esi4-qcStatement-2 (QcEuLimitValue) <10000 NOK> Y

esi4-qcStatement-3 N

esi4-qcStatement-4 (QSCD) YES Y

esi4-qcStatement-5 (PDS-link) https://pds.commfides.com/Legal-Person-Central.pdf Y

esi4-qcStatement-6 (type of certificate)

id-etsi-qcs-QcType 2 Y

Validity (1-5 years) + 14 day Y







https://pds.commfides.com/Legal-Person-Central.pdf


Commfides Norge AS


c. Enterprise_Hard_Enc_13.12


Issuer:




Subject DN:



Y


Y


Y


Y



Y


Y


Y


Key Usage Key Encipherment, Data Encipherment, Key Agreement Y Y


N

Subject alternative name RFC822Name=<Subject emailaddress> Y


Y


Y




Y



Y

Validity (1-12 years **) + 14 days Y


** Validity cannot be longer that the remaining lifetime of the signing CA.







Commfides Norge AS




Issuer:




Subject DN:



Y


Y


Y


Y



Y


Y


N


Y




N


Y


Y


Y




Y











Commfides Norge AS




Issuer:




Subject DN:



Y


Y


Y


Y



Y


Y


N


Y




N


Y


Y


Y




Y


QCStatements

esi4-qcStatement-1 (EU-qualified certificate)

YES Y

esi4-qcStatement-2 (QcEuLimitValue)

<10000 NOK> Y

esi4-qcStatement-3 N

esi4-qcStatement-4 (QSCD) NO N

esi4-qcStatement-5 (PDS-link) https://pds.commfides.com/Legal-Person-Central.pdf Y

esi4-qcStatement-6 (type of certificate)

id-etsi-qcs-QcType 2 Y










Commfides Norge AS


Commfides Norge AS




Issuer:




Subject DN:



Y


Y


Y


Y



Y


Y


N


Y




N


Y


Y


Y




Y












Commfides Norge AS




Issuer:




Subject DN:



Y


Y


Y


Y



Y


Y


N


Y




N


Y


Y


Y




Y


Qualified Certificate Statement <field not in use> N









Commfides Norge AS




Issuer:




Subject DN:



Y


Y


Y


Y



Y


Y


N


Y




N


Y


Y


Y




Y


Qualified Certificate Statement <field not in use> Y

PdsLocation https://pds.commfides.com/Legal-Person-Central.pdf N










Commfides Norge AS




Issuer:




Subject DN:



Y


Y


Y


Y



Y


Y


N


Y




N


Y


Y


Y




Y












Commfides Norge AS

IV. Regarding QC statement

Requirements on QCStatements in EU qualified certificates.

EU qualified certificates shall include QCStatements in accordance with table 2. The column "Presence"

contains the specification of the presence of the statement as follows: • M: Mandatory. The statement

shall be present. • O: Optional. The statement may be present.

Information for this is provided in the Certificate Profile definition for Natural Persons Person High

certificates, Natural Persons Person High certificates for employees, Digital Signature certificate for

Qualified eSeal Certificates and QWAC certificates. The following statements are in use:

1. The OID for Stating that a certificate is Qualified is:

id-etsi-qcs-QcCompliance OBJECT IDENTIFIER ::= { id-etsi-qcs 1 }

2. The OID according to our liability, transaction of 10.000 NOK

id-etsi-qcs-QcLimitValue OBJECT IDENTIFIER ::= { id-etsi-qcs 2 }

esi4-qcStatement-2 QC-STATEMENT ::= { SYNTAX QcEuLimitValue IDENTIFIED

BY id-etsi-qcs-QcLimitValue }

SEQUENCE {currency INTEGER (578), amount INTEGER(5), exponent INTEGER(4) }

MAX AMOUNT NOK 1 EXPONENT 4 (10000 NOK)

3. Statement that our qualified certificates are SSCD

id-etsi-qcs-QcSSCD OBJECT IDENTIFIER ::= { id-etsi-qcs 4 }


Commfides Norge AS

4. QCStatement regarding location of PKI Disclosure Statements (PDS)

id-etsi-qcs-QcPDS OBJECT IDENTIFIER ::= { id-etsi-qcs 5 }

5. QCStatement regarding QCType

id-etsi-qcs-QcType OBJECT IDENTIFIER ::= { id-etsi-qcs 6 } –

-- QC type identifiers

-- Certificate for electronic signatures as defined in Regulation (EU) No 910/2014

id-etsi-qct-esign OBJECT IDENTIFIER ::= { id-etsi-qcs-QcType 1 }

-- Certificate for electronic seals as defined in Regulation (EU) No 910/2014

id-etsi-qct-eseal OBJECT IDENTIFIER ::= { id-etsi-qcs-QcType 2 }

-- Certificate for website authentication defined in Regulation (EU) No 910/2014

id-etsi-qct-web OBJECT IDENTIFIER ::= { id-etsi-qcs-QcType 3 }

V. OCSP Profile

FORMAT

Commfides OCSP service implements the RFC 2560, RFC 6960 and RFC 5019.

BASIC ATTRIBUTES OF THE STATUS CERTIFICATES

Version – version of the status certificate;

o Version 1

Response Type – type of response on the status;

o Basic OCSP response

OCSP Response Status – response status;

o 1 = Good

o 2 = Revoked

o 3 = Unknown

Signature Algorithm

o sha256WithRSAEncryption

STATUS, Available status of the transaction log of the OCSP-Request.


Commfides Norge AS

o SUCCESSFUL = 0;

o MALFORMED_REQUEST = 1;

o INTERNAL_ERROR = 2;

o TRY_LATER = 3;

o SIG_REQUIRED = 5;

o UNAUTHORIZED = 6;

The values used by the OCSP responder are:

issuerDN

serialNumber

status

revocationDate

revocationReason

certificateProfileId

CA certificates and OCSP signer certificates is also in OCSP database. For these certificates the fingerprint,

subjectDN and base64Cert fields must also be included.

OCSP signing key practice

Commfides generates private keys and CSRs in a network HSM connected to the OCSP server, transfer

CSRs to the CA server locally and requests OCSP signing certificates.

Signing certificates are then imported back to HSM and are configured for use in OCSP.

The OCSP requests public key are then matched with the Signing CA and the corresponding OCSP signing

certificate is used to sign the reply.

Commfides uses Signature Algorithm: sha256WithRSAEncryption

Revoked CA certificates

When the first entry in the CA certificate chain matching an OCSP request is revoked with one of the

reason codes "keyCompromise", "cACompromise", "aACompromise" or "unspecified", the status of the

requested certificate will be returned as revoked with reason "cACompromise". This is in accordance with

RFC6960, section 2.7.

Expired certificates

Commfides keeps the status of expired certificates in the database, so the responder will answer queries

also for expired certificates. In the internal CA database the status of expired certificates are set to

ARCHIVED in the database by the CRL creation job. This ARCHIVED status does not affect the response

sent by the OCSP responder. The algorithm is:

If status is CERT_REVOKED the certificate is revoked and reason and date is picked up.

If status is CERT_ARCHIVED and reason is _NOT_ REMOVEFROMCRL or NOT_REVOKED the


Commfides Norge AS

certificate is revoked and reason and date is picked up.

If status is CERT_ARCHIVED and reason is REMOVEFROMCRL or NOT_REVOKED the certificate is

NOT revoked.

If status is neither CERT_REVOKED or CERT_ARCHIVED the certificate is NOT revoked.

The archive cutoff extension is used as defined in RFC 6960.

The contents of the status certificate of Commfides are

OCSP extensions

The standard allows the usage of extensions in OCSP requests and responses.

Nonce

Nonce is the only standard extensions defined. The purpose of the nonce is that a client can verify that a

response really is in response to the specific requests, and not a replayed response. Is is recommended

that if the OCSP requests contains the nonce extension, the OCSP response also contains the nonce.

Commfides included the nonce from the client requests in the server response if the requests contains a

nonce.

NORWEGIAN UNID Extenstion (Based on Norwegian locale SEID leveranse nr. 2)

UNID

UNID is a method used in Norway to map a personal number, Social Security Number (FNR/DNR), to

another number, unid. The unid is used in certificates instead of the real FNR/DNR in order to not reveal

the FNR/DNR to observers. Authorized clients can make special OCSP request, with a special extension, to

translate the unid back to the real FNR/DNR.

EJBCA OCSP can answer OCSP Unid requests, sending back the FNR/DNR to authorized clients.

ocsp.extensionoid=2.16.578.1.16.3.2

If the FNR/DNR returned is null, there are several possible errors:

The client was not authorized to request an FNR/DNR.

There was no Unid FNR/DNR mapping available.

There was no Unid in the certificate (serialNumber DN component).

Example OCSP

OCSP Request Data:

Version: 1 (0x0)

Requestor List:

Certificate ID:

Hash Algorithm: sha1

Issuer Name Hash: 6B40E0BD75488E88F24F69E0B504010B75B6AFF8

Issuer Key Hash: BEAEA7AFB8D6DC6D7EEA9C36FB986C6FEDBF8EC3

Serial Number: 367CC96973A96D64


Commfides Norge AS

Request Extensions:

OCSP Nonce:

0410E9EEEEB355D888A44CF9A7B2E3746401

OCSP Response Data:

OCSP Response Status: successful (0x0)

Response Type: Basic OCSP Response

Version: 1 (0x0)

Responder Id: D7B400F89B47A880C109B93939C3C704B4879280

Produced At: May 29 09:40:21 2017 GMT

Responses:

Certificate ID:

Hash Algorithm: sha1

Issuer Name Hash: 6B40E0BD75488E88F24F69E0B504010B75B6AFF8

Issuer Key Hash: BEAEA7AFB8D6DC6D7EEA9C36FB986C6FEDBF8EC3

Serial Number: 367CC96973A96D64

Cert Status: good

This Update: May 29 09:40:21 2017 GMT

Response Extensions:

OCSP Nonce:

0410E9EEEEB355D888A44CF9A7B2E3746401

Signature Algorithm: sha256WithRSAEncryption

55:98:b6:ef:ca:9f:f9:c7:9e:2a:c5:c9:62:be:41:84:ce:76:…

ommfidesp and ps for ertificatesand qualified entral · 2020-03-25 · ommfides-p-and- ps-for-...

Documents