Certificate Policy and Certification Practice Statement for Telia Email Certificates

Prepared by the Telia’s Certification Authority Policy Management Team

Release: 1.0

Valid From: 2026-01-23

Classification: Public

© Telia Company

No part of this document may be reproduced, modified, or distributed in any form or by any means, in whole or in part, or stored in a database or retrieval system, without prior written permission of Telia. However, permission generally applies for reproducing and disseminating this CPS in its entirety if this is at no charge and that no information in the document is added to, removed or changed.

Revision History

Version	Date	Change	Author
1.0	2026-01-07	The first official version	Telia CA Policy Management Team

1. INTRODUCTION

1.1 Overview

This document is the Certificate Policy and Certification Practice Statement (CP/CPS) for S/MIME certificates, managed by Telia Certification Authority (CA), or here after Telia CA.

This CP/CPS:

• Describes the Certificate Policy (CP) and practices (CPS), responsibility, operational, and technical procedures and practices that Telia CA use in providing certificate services that include, but are not limited to, approving, issuing, using, revoking and managing certificates and operating a X.509 certificate based public key infrastructure (PKIX).
• Management of a repository and informing the roles for parties involved such as Registration Authorities (RA), Subscribers or Relying Parties.

This document is divided into nine sections:

• Section 1 provides an overview of the policy and set of provisions, as well as the types of entities and the appropriate applications for certificates.

• Section 2 contains any applicable provisions regarding identification of the entity or entities that operate repositories, responsibility of a PKI participant to publish information regarding its practices, certificates, and the current status, frequency of publication, and access control on published information.

• Section 3 covers the identification and authentication requirements for certificate related activity.

• Section 4 deals with certificate life-cycle management and operational requirements including application for a certificate, revocation, suspension, audit, archival and compromise.

• Section 5 covers facility, management and operational controls (physical and procedural security requirements).

• Section 6 provides the technical controls with regard to cryptographic key requirements.

• Section 7 defines requirements for certificate, Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) formats. This includes information on profiles, versions, and extensions used.

• Section 8 addresses topics covered, and methodology used for assessments/audits, frequency of compliance audits or assessments, identity and/or qualifications of the personnel performing the audit or assessment, actions taken as a result of deficiencies found during the assessment, and who is entitled to see results of an assessment.

• Section 9 covers general business and legal matters: the business issues of fees, liabilities, obligations, legal requirements, governing laws, processes, and confidentiality.

Telia Certificate Authority conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates published at https://www.cabforum.org. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this CPS.

This CPS conforms to the IETF PKIX Internet X.509 Public Key Infrastructure CP and CPS Framework (RFC 3647).

Telia Certificates do not, however, provide any guarantee that the Subject named in the Certificate is trustworthy, honest, or reputable in its business dealings, or safe to do business with. Issued certificates only establish that Telia CA verified that the business was legally organised, used domain names were owned or managed by the Subject.

In summary following certificate types (“Services”) are offered by Telia, equivalent to LCP, NCP or NCP+ as defined by ETSI EN 319 401 and ETSI EN 319 411-1:

1. Telia S/MIME mailbox-validated certificate: to authenticate mailbox control. The mailbox domain name is validated by Telia CA.

2. Telia S/MIME organization-validated certificate: to authenticate mailbox control and subject organization identity. The mailbox domain name is validated by Telia CA.

3. Telia S/MIME sponsor-validated certificate: to authenticate mailbox control, organization identity and organization subject identity. The mailbox domain name is validated by Telia CA.

1.2 Document name and identification

This CP/CPS is identified by the following information:

• Name: Certificate Policy and Certification Practice Statement for Telia Email Certificates
• Release: As stated on the cover page
• OID: 1.3.6.1.4.1.271.2.3.1.2.1
• Location: https://cps.trust.telia.com/

This CPS is also a CP for Telia S/MIME certificates. The certificates issued according to this CPS contain CP OID corresponding to the applicable certificate type. The routines and roles resulting from this CPS apply only in connection with certificates referring to the following Certificate Policy OIDs:

CA	Type	CA CP OID	Subscriber Certificate CP OID	Technically Constrained
Telia Root CA v2	Root CA	N/A	N/A
Telia RSA Email Root CA v3	Root CA	N/A	N/A
Telia EC Email Root CA v3	Root CA	N/A	N/A
Telia RSA Email Root CA v3	Cross-Certified Subordinate CA	2.5.29.32.0	N/A
Telia EC Email Root CA v3	Cross-Certified Subordinate CA	2.5.29.32.0	N/A
Telia RSA Email CA v6	S/MIME certificates	2.5.29.32.0	2.23.140.1.5.1.2, 2.23.140.1.5.1.3, 2.23.140.1.5.2.2, 2.23.140.1.5.2.3, 2.23.140.1.5.3.2, 2.23.140.1.5.3.3, 1.3.6.1.4.1.271.2.3.1.1.14
Ericsson NL Individual CA v5	S/MIME certificates for Telefonaktiebolaget LM Ericsson	2.23.140.1.5.1.2, 2.23.140.1.5.1.3, 2.23.140.1.5.2.2, 2.23.140.1.5.2.3, 2.23.140.1.5.3.2, 2.23.140.1.5.3.3, 1.3.6.1.4.1.271.2.3.1.1.18	2.23.140.1.5.1.2, 2.23.140.1.5.1.3, 2.23.140.1.5.2.2, 2.23.140.1.5.2.3, 2.23.140.1.5.3.2, 2.23.140.1.5.3.3, 1.3.6.1.4.1.271.2.3.1.1.18	YES
Telia RSA Email CA v5	S/MIME certificates	1.3.6.1.4.1.271.2.3.1.1.14, 2.23.140.1.5.1.1, 2.23.140.1.5.3.1	1.3.6.1.4.1.271.2.3.1.1.14, 2.23.140.1.5.1.1, 2.23.140.1.5.3.1
Ericsson NL Individual CA v4	S/MIME certificates for Telefonaktiebolaget LM Ericsson	1.3.6.1.4.1.271.2.3.1.1.18, 2.23.140.1.5.1.1, 2.23.140.1.5.3.1	1.3.6.1.4.1.271.2.3.1.1.18, 2.23.140.1.5.1.1, 2.23.140.1.5.3.1	YES

NOTE	Telia Email CA v5 and Ericsson NL Individual CA v4 are part of Telia CA’s S/MIME PKI, but have ceased issuance since June 2025 before Legacy generation S/MIME certificates were probibited by the BR. The CAs are kept in this CP/CPS and included in Telia CAs audits until revoked after the last active non-revoked subscriber certificate has expired.

1.3 PKI participants

Telia Root CAs Telia Root CA v2, Telia RSA Email Root CA v3 and Telia EC Email Root CA v3 issue Subordinate CA certificates to Telia and Subscribers hosting their CA at Telia.

NOTE	Telia RSA Email Root CA v3 and Telia EC Email Root CA v3 are NOT yet included in any root program providing public trust in the global PKI domain.

Telia Email Certificate contains a Public Key bound to a Mailbox Address and MAY also contain the identity of a Natural Person or Legal Entity that controls such email address. The Key Pair can then be used to sign, verify, encrypt, and decrypt email.

Telia Email certificates are issued registered Subscribers of Telia CA. All the participating organizations shall undertake what is stated in this CP/CPS.

1.3.1 Certification authorities

The CA operating in compliance with this CPS is Telia CA. The legal entity responsible of Telia CA is Finnish company “Telia Finland Oyj” (BusinessID 1475607-9). Telia Finland Oyj is part of Swedish company “Telia Company AB” (BusinessID 5561034249).

The name of the CA in the “Issuer” field of the certificate is one of the issuing CA names listed in chapter 1.2.

Figure 1 presents Telia CA’s S/MIME PKI hierarchy self-signed Root CAs Telia RSA Email Root CA v3 and Telia EC Email Root CA v3. Both self-signed Root CAs have been cross-certified by Telia Root CA v2. Telia RSA Email Root CA v3 self-signe root CA certificate and cross-certified Telia RSA TLS Root CA v3 subordinate certificate have the same key pair and subject. Telia EC Email Root CA v3 self-signed root CA certificate and cross-certified Telia EC Email Root CA v3 subordinate certificate have the same key pair and subject. Clients can use either one when doing PKI path validation.

In the hierarchy of subordinate CAs up to self-signe root CAs (see Figure 1, the Telia CA is responsible for ensuring the subordinate CAs comply with the applicable policy requirements.

The CAs are responsible for managing the certificate life cycle of End-Entity certificates signed by the CAs. This will include:

• Creating and signing of certificates binding Subjects with their public key

• Promulgating certificate status through CRLs and/or OCSP responders

This CPS covers all certificates issued and signed by the following CAs.

Root CAs

CA	SHA Fingerprint
Telia Root CA v2	242B69742FCB1E5B2ABF98898B94572187544E5B4D9911786573621F6A74B82C
Telia RSA Email Root CA v3	5B0C502A7D963BA55217396FDA9B3DC78171000AEEFF42CECC3A20A7938163E8
Telia EC Email Root CA v3	3682228D7D678B571440CF1CB34E69FB4135FD6C2A1BE38E14163B711E02AE01

Cross-Certified Subordinate CAs

CA	SHA Fingerprint
Telia RSA Email Root CA v3	D46F8990078A9B2AE08F3C50E9CB1A07373D574003A66BB72EC3A99CBE2A3382
Telia EC Email Root CA v3	18C2FC38AFD8E668A89A6FC1E8A924C8D5C6BD1A70089FDDE56361CDA92EF445

Subordinate CAs

CA	SHA Fingerprint
Ericsson NL Individual CA v4	EE0343093DF71E364606100164C62A4FB8C4A0F32B1EB47860FFD6C17E94CA54
Telia Email CA v5	E26BA792CDF9E21B6402044DD9A61E2E1537D5FFD22EE2478979408E3233310A
Ericsson NL Individual CA v5	6A1ADE9A5BB8AE0782A2325AF163B2D2305413403734D5DE59977ACA7D3D4882
Telia RSA Email CA v6	BD6E7EDCEBE62E4571F180001568F861DE2AA7AF6D98E7C338D426F54123785B

Externally Operated Subordinate CAs

Telia CA does not allow externally operated Subordinate Certificate Authorities in its S/MIME PKI hierarchies.

1.3.2 Registration authorities

The CA’s units are authorised to perform registration functions. Through those agreements, RAs are obliged to follow this CPS for their part.

The RA responsibilities for the following activities on behalf of a CA include:

• Identification and authentication of certificate subjects
• Initiating or passing along revocation requests for certificates
• Approving applications for renewal or re-keying certificates

All RA functions in this CPS are performed internally by Telia. Telia will not delegate domain validation to be performed by a third-party.

1.3.3 Subscribers

Subscribers are legal entities to whom Certificates are issued according to this CPS. For S/MIME certificates the Subscriber may only be a legal entity (e.g. an organization).

1.3.4 Relying parties

A Relying Party may be either a Subscriber of any Telia CA or any other organization, person or application that is relying on a valid certificate issued by any of the CAs in this CPS that are chained to a Telia self-signed Root CA.

1.3.5 Other participants

Telia has made agreements with Application Software Suppliers so that they may trust, and display certificates issued by Telia as trusted when used via their software.

1.4 Certificate usage

1.4.1 Appropriate certificate uses

Certificates under this CPS are issued to legal entity subjects to be used for the following applications:

• Root certificates: used to create subCAs
• Cross-certifier Subordinate CAs to provide interoperability across Root CA hierarchies.
• S/MIME subscriber certificates: used to secure email communication by the legal entity subjects.

CA	Appropriate usage
Telia Root CA v2 Telia RSA Email Root CA v3 Telia EC TLS Root CA v3	CAs issue certificates for subordinate CAs.
Telia RSA Email Root CA v3 Telia EC Email Root CA v3	Cross-certified subordinate CAs to allow interoperability across Telia Root v2 and Telia Email Root v3 hierarchies for S/MIME subscriber certificates.
Telia RSA Email CA v6 Ericsson NL Individual CA v5	Subordinate CA Certificates used for mailbox, organization or sponsor-validated subscriber S/MIME certificates

1.4.2 Prohibited certificate uses

Applications using certificates issued under this CPS shall consider the key usage purpose stated in the “Key Usage” and “Extended Key Usage” extension fields of the certificate.

Additionally, the key usage purposes and limitations possibly stated in the contract between the Subscriber and the CA shall be considered when using certificates.

1.5 Policy administration

1.5.1 Organization administering the document

The Telia CA Policy Management Team (PMT) is the responsible authority for reviewing and approving this CP/CPS. Written and signed comments on proposed changes shall be directed to the Telia contact as described in Section 1.5.2. Decisions with respect to the proposed changes are at the sole discretion of the PMT.

Contact information:

Telia Finland Oyj Pasilan Asema-aukio 1 FI-00520 Helsinki, Finland Phone: +358 (0) 20401 Internet: https://cps.trust.telia.com/ Business ID: 1475607-9

1.5.2 Contact person

Contact point in matters related to this CPS:

Telia CA Policy Management Team (PMT) Email: cainfo@telia.fi Phone: +358 (0) 20401 Internet: https://cps.trust.telia.com/

Other contact information:

Customer Service: +358 20 693 693 (normal office hour Help Desk services) CA Customer Service: cainfo@telia.fi (PKI support issues) Revocation Service Phone: +358 (0) 800156677 (revocation requests or any urgent issues) Revocation Service Web: https://support.trust.telia.com/certificate_revocation_request_en.html

Certificate problem reporting:

Subscribers, relying parties, application software vendors, and other third parties can use two optional methods to contact Telia CA:

Customer service: cainfo@telia.fi, Weekdays during office hours in Finland Problem reporting: ca-problems@telia.fi, Always handled within 24 hours

Use either of these channels to report complaints or suspected private key compromise, certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to certification. In urgent cases we recommend contacting Telia Company or revoking the certificate by calling and using the above contact phone numbers also.

To ensure that problem reports are duly received and processed, Telia CA does NOT accept attachment in the problem report emails. Should the reported case require exchange of additional materials that cannot be included in the email text the reporter MUST inform Telia CA in the initial report. Telia CA SHALL instruct reporter of the means to deliver such information when responding to the initial report.

Problem reporting instructions, please see: https://support.trust.telia.com/palvelinvarmenneturvallisuus_en.html

1.5.3 Person determining CPS suitability for the policy

The PMT is the authority for determining this CPS suitability to the applicable policies.

1.5.4 CPS approval procedures

The PMT will review any modifications, additions or deletions from this CPS and determine if modifications, additions, or deletions are acceptable and do not jeopardize operations or the security of the production environment.

The PMT shall review whole CPS on annual basis. Such review is recorded in the CPS changelog as new CPS version and published according to Telia CA’s CPS management policy.

1.6 Definitions and acronyms

1.6.1 Definitions

Term	Definition
Affiliate	A corporation, partnership, joint venture or other entity controlling, controlled by, or under common control with another entity, or an agency, department, political subdivision, or any entity operating under the direct control of a Government Entity.
Applicant	The Natural Person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual Certificate Request.
Applicant Representative	A Natural Person or human sponsor who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant: • who signs and submits, or approves a Certificate Request on behalf of the Applicant; • who signs and submits a Subscriber Agreement on behalf of the Applicant; and/or • who acknowledges the Terms of Use on behalf of the Applicant when the Applicant is an Affiliate of the CA or is the CA.
Application Software Supplier	A supplier of email client software or other relying-party application software such as mail user agents (web-based or application based) and email service providers that process S/MIME Certificates.
Assumed Name	Also known as “doing business as”, “DBA”, or “d/b/a” name in the US and “trading as” name in the UK.
Attestation	A letter attesting that Subject Information is correct written by an accountant, lawyer, government official, or other reliable third party customarily relied upon for such information.
Audit Period	In a period-of-time audit, the period between the first day (start) and the last day of operations (end) covered by the auditors in their engagement. (This is not the same as the period of time when the auditors are on-site at the CA.) The coverage rules and maximum length of audit periods are defined in Section 8.1.
Audit Report	A report from a Qualified Auditor stating the Qualified Auditor’s opinion on whether an entity’s processes and controls comply with the mandatory provisions of these Requirements.
CA Key Pair	A Key Pair where the Public Key appears as the Subject Public Key Info in one or more Root CA Certificate(s) and/or Subordinate CA Certificate(s).
Certificate	An electronic document that uses a digital signature to bind a Public Key and an identity.
Certification Authority (or CA)	An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Root CAs and Subordinate CAs.
Certification Authority Authorization (or CAA)	From RFC 9495: “The Certification Authority Authorization (CAA) DNS resource record (RR) provides a mechanism for domains to express the allowed set of Certification Authorities that are authorized to issue certificates for the domain.”
Certificate Data	Certificate requests and data related thereto (whether obtained from the Applicant or otherwise) in the CA’s possession or control or to which the CA has access.
Certificate Management Process	Processes, practices, and procedures associated with the use of keys, software, and hardware, by which the CA verifies Certificate Data, issues Certificates, maintains a Repository, and revokes Certificates.
Certificate Policy (or CP)	A set of rules that indicates the applicability of a named Certificate to a particular community and/or PKI implementation with common security requirements.
Certification Practice Statement (or CPS)	One of several documents forming the governance framework in which Certificates are created, issued, managed, and used.
Certificate Problem Report	Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.
Certificate Profile	A set of documents or files that defines requirements for Certificate content and Certificate extensions in accordance with Section 7 e.g., a section in a CA’s CPS or a Certificate template file used by CA software.
Certificate Revocation List	A regularly updated time-stamped list of revoked Certificates that is created and digitally signed by the CA that issued the Certificates.
Certificate Type	The S/MIME Baseline Requirements define Certificate Profiles differentiated by the type of Subject, (for example Mailbox, Organization, Sponsored, Individual).
Control	“Control” (and its correlative meanings, “controlled by” and “under common control with”) means possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors; or (3) vote that portion of voting shares required for “control” under the law of the entity’s Jurisdiction of Incorporation or Registration but in no case less than 10%.
Conversion	The process of converting text from one writing system to ASCII characters.
Country	Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations.
Cross Certificate	A Certificate that is used to establish a trust relationship between two Root CAs.
CSPRNG	A pseudo-random number generator intended for use in a cryptographic system.
Delegated Third Party	A Natural Person or Legal Entity that is not the CA but is authorized by the CA, and whose activities are not within the scope of the appropriate CA audits, to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein.
Digital Identity Document	A government-issued identity document that is issued in a machine-processable form, that is digitally signed by the issuer, and that is in purely digital form.
Domain Label	From RFC 8499: “An ordered list of zero or more octets that makes up a portion of a domain name. Using graph theory, a label identifies one node in a portion of the graph of all possible domain names.”
Domain Name	An ordered list of one or more Domain Labels assigned to a node in the Domain Name System.
Electronic Identification (eID)	A credential containing Individual identification data and/or attributes and which is used for authentication for an online service.
Enterprise RA	An employee or agent of an organization unaffiliated with the CA who authorizes issuance of Certificates to that organization.
European Unique Identifier (EUID)	The EUID uniquely identifies officially-registered organizations, Legal Entities, and branch offices within the European Union or the European Economic Area. The EUID is specified in chapter 9 of the Annex contained in the Implementing Regulation (EU) 2021/1042 which describes rules for the application of Directive (EU) 2017/1132 “relating to certain aspects of company law (codification)”.
Expiry Date	The “Not After” date in a Certificate that defines the end of a Certificate’s validity period.
Extant S/MIME CA	A Subordinate CA that: • Is a Publicly-Trusted Subordinate CA Certificate whose notBefore field is before September 1, 2023 and which is included in a valid trust chain of an end entity S/MIME Certificate; • The CA Certificate includes no Extended Key Usage extension, contains anyExtendedKeyUsage in the EKU extension, or contains id-kp-emailProtection in the EKU extension; • The CA Certificate complies with the profile defined in RFC 5280. The following two deviations from the RFC 5280 profile are acceptable: – The CA Certificate contains a nameConstraints extension that is not marked critical; – The CA Certificate contains a policy qualifier of type UserNotice which contains explicitText that uses an encoding that is not permitted by RFC 5280 (i.e., the DisplayText is encoded using BMPString or VisibleString); and • The CA Certificate contains the anyPolicy identifier (2.5.29.32.0) or specific OIDs in the certificatePolicies extension that do not include those defined in Section 7.1.6.1 of these Requirements.
Fully-Qualified Domain Name	A Domain Name that includes the Domain Labels of all superior nodes in the Internet Domain Name System.
Generation	The S/MIME Baseline Requirements define several Generations of Certificate Profile for each Certificate Type.
Government Entity	A government-operated legal entity, agency, department, ministry, branch, or similar element of the government of a country, or political subdivision within such country (such as a state, province, city, county, etc.).
Individual	A Natural Person.
Individual-Validated	Refers to a Certificate Subject that includes only Individual (Natural Person) attributes, rather than attributes linked to an Organization.
Issuing CA	In relation to a particular Certificate, the CA that issued the Certificate. This could be either a Root CA or a Subordinate CA.
Jurisdiction of Incorporation	The country and (where applicable) the state or province or locality where the organization’s legal existence was established by a filing with (or an act of) an appropriate government agency or entity (e.g., where it was incorporated). In the context of a Government Entity, the country and (where applicable) the state or province where the Entity’s legal existence was created by law.
Key Compromise	A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it.
Key Generation Script	A documented plan of procedures for the generation of a CA Key Pair.
Key Pair	The Private Key and its associated Public Key.
Legacy Profile	The S/MIME Legacy Generation profiles provide flexibility for existing reasonable S/MIME certificate practices to become auditable under the S/MIME Baseline Requirements. This includes options for Subject DN attributes, extKeyUsage, and other extensions. The Legacy Profiles will be deprecated in a future version of the S/MIME Baseline Requirements.
Legal Entity	An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country’s legal system.
Linting	A process in which the content of digitally signed data such as a Precertificate [RFC 6962], Certificate, CRL, or OCSP response, or data-to-be-signed object such as a tbsCertificate (as described in RFC 5280, Section 4.1.1.1) is checked for conformance with the profiles and requirements defined in these Requirements.
Mailbox-Validated (MV)	Refers to a Certificate Subject that is limited to (optional) subject:emailAddress and/or subject:serialNumber attributes.
Mailbox Address	Also Email Address. The format of a Mailbox Address is defined as a “Mailbox” as specified in Section 4.1.2 of RFC 5321 and amended by Section 3.2 of RFC 6532, with no additional padding or structure.
Mailbox Field	In Subscriber Certificates contains a Mailbox Address of the Subject via rfc822Name or otherName value of type id-on-SmtpUTF8Mailbox in the subjectAltName extension, or in Subordinate CA Certificates via rfc822Name in permittedSubtrees within the nameConstraints extension.
Multi-Perspective Issuance Corroboration	A process by which the determinations made during domain validation and CAA checking by the Primary Network Perspective are corroborated by other Network Perspectives before Certificate issuance.
Multipurpose Profile	The S/MIME Multipurpose Generation profiles are aligned with the more defined Strict Profiles, but with additional options for extKeyUsage and other extensions. This is intended to allow flexibility for crossover use cases between document signing and secure email.
Natural Person	An Individual; a human being as distinguished from a Legal Entity.
Network Perspective	Related to Multi-Perspective Issuance Corroboration. A system (e.g., a cloud-hosted server instance) or collection of network components (e.g., a VPN and corresponding infrastructure) for sending outbound Internet traffic associated with a domain control validation method and/or CAA check. The location of a Network Perspective is determined by the point where unencapsulated outbound Internet traffic is typically first handed off to the network infrastructure providing Internet connectivity to that perspective.
Object Identifier	A unique alphanumeric or numeric identifier registered under the International Organization for Standardization’s applicable standard for a specific object or object class.
OCSP Responder	An online server operated under the authority of the CA and connected to its Repository for processing Certificate status requests. See also, Online Certificate Status Protocol.
Online Certificate Status Protocol	An online Certificate-checking protocol that enables relying-party application software to determine the status of an identified Certificate. See also OCSP Responder.
Organization-Validated	Refers to a Certificate Subject that includes only Organizational (Legal Entity) attributes, rather than attributes linked to an Individual.
Parent Company	A company that Controls a Subsidiary Company.
Personal Name	Personal Name is a name of an Individual Subject typically presented as subject:givenName and/or subject:surname. However, the Personal Name may be in a format preferred by the Subject, the CA, or Enterprise RA as long as it remains a meaningful representation of the Subject’s verified name.
Physical Identity Document	A government-issued identity document issued in physical and human-readable form (such as a passport or national identity card).
Primary Network Perspective	The Network Perspective used by the CA to make the determination of 1) the CA’s authority to issue a Certificate for the requested domain(s) or IP address(es) and 2) the Applicant’s authority and/or domain authorization or control of the requested domain(s) or IP address(es).
Private Key	The key of a Key Pair that is kept secret by the holder of the Key Pair, and that is used to create Digital Signatures and/or to decrypt electronic records or files that were encrypted with the corresponding Public Key.
Pseudonym	A fictitious identity that a person assumes for a particular purpose. Unlike an anonymous identity, a pseudonym can be linked to the person’s real identity.
Public Key	The key of a Key Pair that can be publicly disclosed by the holder of the corresponding Private Key and that is used by a Relying Party to verify Digital Signatures created with the holder’s corresponding Private Key and/or to encrypt messages so that they can be decrypted only with the holder’s corresponding Private Key.
Public Key Infrastructure	A set of hardware, software, people, procedures, rules, policies, and obligations used to facilitate the trustworthy creation, issuance, management, and use of Certificates and keys based on Public Key Cryptography.
Publicly-Trusted Certificate	A Certificate that is trusted by virtue of the fact that its corresponding Root CA Certificate is distributed as a trust anchor in widely-available application software.
Qualified Auditor	A Natural Person or Legal Entity that meets the requirements of Section 8.2.
Random Value	A value specified by a CA to the Applicant that exhibits at least 112 bits of entropy.
Registered Domain Name	A Domain Name that has been registered with a Domain Name Registrar.
Registration Authority (RA)	Any Legal Entity that is responsible for identification and authentication of subjects of Certificates, but is not a CA, and hence does not sign or issue Certificates. An RA MAY assist in the certificate application process or revocation process or both. When “RA” is used as an adjective to describe a role or function, it does not necessarily imply a separate body, but can be part of the CA.
Registration Reference	An identifier assigned to a Legal Entity.
Registration Scheme	A scheme for assigning a Registration Reference meeting the requirements identified in Appendix A.
Reliable Data Source	An identification document or source of data used to verify Subject Identity Information that is generally recognized among commercial enterprises and governments as reliable, and which was created by a third party for a purpose other than the Applicant obtaining a Certificate.
Reliable Method of Communication	A method of communication, such as a postal/courier delivery address, telephone number, or email address, that was verified using a source other than the Applicant Representative.
Relying Party	Any Natural Person or Legal Entity that relies on a Valid Certificate. An Application Software Supplier is not considered a Relying Party when software distributed by such Supplier merely displays information relating to a Certificate.
Repository	An online database containing publicly-disclosed PKI governance documents (such as Certificate Policies and Certification Practice Statements) and Certificate status information, either in the form of a CRL or an OCSP response.
Requirements	The S/MIME Baseline Requirements found in this document.
Root CA	The top level Certification Authority whose Root CA Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.
Root CA Certificate	The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs.
Sovereign State	A state or country that administers its own government, and is not dependent upon, or subject to, another power.
Sponsor-validated	Refers to a Certificate Subject which combines Individual (Natural Person) attributes in conjunction with an subject:organizationName (an associated Legal Entity) attribute. Registration for Sponsor-validated Certificates MAY be performed by an Enterprise RA where the subject:organizationName is either that of the delegated enterprise, or an Affiliate of the delegated enterprise, or that the delegated enterprise is an agent of the named Subject Organization.
Strict Profile	The S/MIME Strict Generation profiles are the long term target profile for S/MIME Certificates with extKeyUsage limited to id-kp-emailProtection, and stricter use of Subject DN attributes and other extensions.
Subject	The Natural Person, device, system, unit, or Legal Entity identified in a Certificate as the Subject. The Subject is either the Subscriber or a mailbox under the control and operation of the Subscriber.
Subject Identity Information	Information that identifies the Certificate Subject. Subject Identity Information does not include a Mailbox Address listed in the subject:commonName or subject:emailAddress fields, or in the subjectAltName extension.
Subordinate CA	A Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA.
Subscriber	A Natural Person or Legal Entity to whom a Certificate is issued and who is legally bound by a Subscriber Agreement or Terms of Use.
Subscriber Agreement	An agreement between the CA and the Applicant/Subscriber that specifies the rights and responsibilities of the parties.
Subsidiary Company	A company that is controlled by a Parent Company.
Supplementary Evidence	Used in addition to authoritative evidence to strengthen the reliability of the identity verification and/or as evidence for attributes that are not evidenced by the authoritative evidence.
Technically Constrained Subordinate CA Certificate	A Subordinate CA Certificate which uses a combination of Extended Key Usage settings and Name Constraint settings to limit the scope within which the Subordinate CA Certificate MAY issue Certificates to Subscriber or additional Subordinate CAs.
Terms of Use	Provisions regarding the safekeeping and acceptable uses of a Certificate issued in accordance with these Requirements when the Applicant/Subscriber is an Affiliate of the CA or is the CA.
Valid Certificate	A Certificate that passes the validation procedure specified in RFC 5280.
Validation Specialist	Someone who performs the information verification duties specified by these Requirements.
Validity Period	From RFC 5280: “The period of time from notBefore through notAfter, inclusive.”

1.6.2 Acronyms

Acronym	Meaning
AATL	Adobe Approved Trust List
BR	Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates
CA	Certification Authority
CP	Certificate Policy
CPS	Certification Practice Statement
CRL	Certificate Revocation List
DBA	Doing Business As
DER	Distinguished Encoding Rules
DN	Distinguished Name
DSA	Digital Signature Algorithm
DV	Domain Validation
ETSI	European Telecommunications Standards Institute
FIPS	Federal Information Processing Standard
FQDN	Fully Qualified Domain Name
HSM	Hardware Security Module
IETF	Internet Engineering Task Force
ISO	International Organization for Standardization
LDAP	Lightweight Directory Access Protocol
NTP	Network Time Protocol
OCSP	On-line Certificate Status Protocol
OID	Object Identifier
PDF	Portable Document Format
PIN	Personal Identification Number
PKCS	Public Key Cryptography Standards
PKI	Public Key Infrastructure
PKIX	Public Key Infrastructure X.509 (IETF Working Group)
PMT	Policy Management Team
RA	Registration Authority
RFC	Request for Comments
RSA	Rivest-Shamir-Adleman asymmetric encryption algorithm
S/MIME	Secure Multipurpose Internet Mail Extension
SHA	Secure Hash Algorithm
TLS	Transport Layer Security
URI	Uniform Resource Identifier
URL	Uniform Resource Locator
VPN	Virtual Private Network

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1 Repositories

2.1.1 CPS Repository

A full text version of this CPS is published at the Repository https://cps.trust.telia.com/.

2.1.2 Revocation Information Repository

Following CRLs are published on the Telia’s website:

Issuing CA	CRL addresses
Telia Root CA v2	http://httpcrl.trust.telia.com/teliarootcav2.crl
Telia RSA Email Root CA v3	http://httpcrl.trust.telia.com/teliarsaemailrootcav3.crl
Telia EC Email Root CA v3	http://httpcrl.trust.telia.com/teliaecemailrootcav3.crl
Telia Email CA v5	http://httpcrl.trust.telia.com/teliaemailcav5.crl
Telia RSA Email CA v6	http://httpcrl.trust.telia.com/teliarsaemailcav6.crl
Ericsson NL Individual CA v4	http://httpcrl.trust.telia.com/ericssonnlindividualcav4.crl
Ericsson NL Individual CA v5	http://httpcrl.trust.telia.com/ericssonnlindividualcav5.crl

Telia OCSP service is available at URL http://ocsp.trust.telia.com.

2.1.3 Certificate Repository

CA certificates are published at the Repository. All issued certificates are stored in the local database of the CA system. Certificates may also be published to other repositories if it is a part of the Telia CA Service or agreed with a Subscriber.

The Repository will be available 24 hours per day, 7 days per week. If there will be a technical failure, that should not affect the availability of the services significantly more than 48 hours.

2.2 Publication of certification information

It is Telia’s role to make the following information available:

1. This CPS

2. CRLs and revocation status of revoked certificates

3. Issued CA certificates and cross certificates for cross-certified CAs

Telia may publish and supply certificate information in accordance with applicable legislation.

Each published CRL provides all processed revocation information at the time of publication for all revoked certificates of which the revocation list is intended to give notification.

Telia supplies CA certificates for all public CA keys provided these can be used for verifying valid certificates.

Subscribers will be notified that a CA may publish information submitted by them to publicly accessible directories in association with certificate information. The publication of this information will be within the limits of sections 9.3 and 9.4.

2.3 Time or frequency of publication

This CPS is reviewed and updated or modified versions are published at least once per year and in accordance with section 9.12.

2.4 Access controls on repositories

This CPS, CRLs and CA certificates are publicly available using read-only access. Only authorised CA personnel have access to information stored in the local database of the CA system.

3. IDENTIFICATION AND AUTHENTICATION

3.1 Naming

3.1.1 Types of names

An X.501 Distinguished Name (DN) together with Subject Alternative Name values are used as an unambiguous name of the Subscriber.

3.1.1.1 Root CA

The following attributes are used in the Subject field of the root CA certificates:

Root CA	commonName, CN (OID 2.5.4.3)	organizationName, O (OID 2.5.4.10)	countryName, C (OID 2.5.4.6)
Telia Root CA v2	Telia Root CA v2	Telia Finland Oyj	FI
Telia RSA Email Root CA v3	Telia RSA Email Root CA v3	Telia Company AB	SE
Telia EC Email Root CA v3	Telia EC Email Root CA v3	Telia Company AB	SE

Cross-certified Subordinate CAs for interoperability purposes have the exact same Subject information as the corresponding Self-signed Root CA.

3.1.1.2 Subordinate CAs

The following attributes are used in the Subject field of the subCA certificates:

Attribute	Description of value
commonName (CN, OID 2.5.4.3)	Name of the subordinate CA
organizationName (O, OID 2.5.4.10)	Name of the CA organization. The name is either Telia Company AB or Telia Finland Oyj
countryName (C, OID 2.5.4.6)	Country where the CA organization is incorporated

3.1.1.3 Subscriber Certificates

The following attributes are used in the Subject field of the Subscriber certificates:

Attribute	Description – Organization and Sponsor validated	Description – Mailbox validated
commonName (CN, OID 2.5.4.3)	Mailbox Address of the Subject	Mailbox Address of the Subject
organizationName (O, OID 2.5.4.10)	Subscriber in relation to which the Subject is identified. Common variations or abbreviations may also be used provided that the name owner is unambiguous.	Not allowed
organizationIdentifier (OID 2.5.4.97)	The value is the NTR Registration Scheme identifier, where registrations are administrated at country level, a 2 character ISO 3166-2 identifier for the nation in which the Registration Scheme is operated, preceded by a hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8))	Not allowed
Surname (S, OID 2.5.4.4)	Family name of the Subject	Not allowed
givenName (G, OID 2.5.4.42)	Subject’s names, which are not family name	Not allowed
Locality (L, OID 2.5.4.7)	City name. A component of the address of the physical location of the Subject’s Place of Business.	Not allowed
countryName (C, OID 2.5.4.6)	Two-character country code. A component of the address of the physical location of the Subject’s Place of Business.	Not allowed
streetAddress (OID 2.5.4.9)	Optional Street address A component of the address of the physical location of the Subject’s Place of Business.	Not allowed
postalCode (OID 2.5.4.17)	Optional. Postal code. A component of the address of the physical location of the Subject’s Place of Business.	Not allowed
emailAddress (E, OID 1.2.840.113549.9.1)	Subject’s email address.	Not allowed
subjectAltName (OID 2.5.29.17) rfc822Name If rfc822name has international characters, then punycode converted version of the string will be used.	E-mail address of the Subject	E-mail address of the Subject

Distinguished Name (DN) or Subject Alternative Name attributes are verified by the CA. None of the Subject attributes contains only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.

3.1.2 Need for names to be meaningful

Names will be meaningful as stated in the section 3.1.1.

3.1.3 Anonymity or pseudonymity of Subscribers

Telia CA does not allow pseudonyms in the certificates.

3.1.4 Rules for interpreting various name forms

Distinguished Names in Certificates are interpreted using X.500 standards and ASN.1 syntax.

The Organization (O) attribute states the Subscriber Organization in relation to which the Subject is identified. Normally Organization attribute contains the registered name of the Organization with or without the abbreviation for the form of company incorporation. In some cases, the CA may also accept an Organization name attribute that is other than the official registered name of the Organization, if the name is commonly used or there is otherwise no risk of confusion.

3.1.4.1 Non ASCII character substitution

Telia may allow the Conversion of Subject Identity Information usually rendered in non-ASCII characters (including Accent or Umlaut-accented characters) using a system defined by the International Organization for Standardization (ISO) regardless of capitalization:

• Accent characters may be represented by their ASCII equivalent. For example é, à, í, ñ, or ç may be represented by e, a, i, n, or c, respectively.
• Umlaut-accented characters such as ä, ö, ü may be represented by either ae, oe, ue or a, o, u, respectively.

Telia may include an ASCII character name that is not a direct Conversion of the Applicant’s registered name provided that it is verified in a Reliable Data Source or suitable Attestation.

3.1.4.2 Geographic names

Telia may use geographic endonyms and exonyms in the subject:localityName and subject:stateOrProvinceName attributes, (e.g., Munich, Monaco di Bavaria, or Мюнхен for München). Telia CA avoids the use of archaic geographic names.

3.1.5 Uniqueness of names

The Subject name stated in a certificate will be unique for all certificates issued within the domain of the CA and conform to X.500 standards for name uniqueness. Subject name uniqueness means that the CA will not issue certificates with identical names to different entities. However, the CA may issue several certificates to the same entity, and in that case, the Subject names in those certificates may be the same.

Unambiguousness of the Subject names is secured in a two-phase procedure. A name contains both the name of the organization and the name of the Subject. The CA system allows only unambiguous organization names. The Subscriber Organization is not able to change the organization name that the CA has recorded for the organization in the CA system. The Subscriber Organizations are responsible for the unambiguousness of the names of their subjects.

3.1.6 Recognition, authentication, and role of trademarks

The priority to entity names is given to registered trademark holders.

The use of an email address is restricted to the authenticated legal owner of that email address.

Telia does not otherwise check the right of the Subscriber Organization to use the names it gives in its certificate applications except for the Organization Name as stated in section 3.2.2, nor does the CA participate in any name claim dispute resolution procedures concerning brand names, domain names, trademarks, or service names.

Telia reserves the right not to issue such a certificate, or to revoke a certificate that has already been issued when there is a name claim dispute involved concerning the certificate contents.

3.2 Initial identity validation

This section describes the Telia CA identification and authentication procedures for registration of subjects. Validation practice introduced in this section governs both Publicly Trusted S/MIME validation and other certificate types governed by this CP/CPS. Separation between the two is clearly indicated in applicable subsections as seen necessary.

Telia CA implements Multipurpose and Strict Generation Publicly Trusted S/MIME Certificates for:

• Mailbox-validated
• Organization-validated and
• Sponsor-validated

profiles defined by the BR. See section 1.3 for S/MIME certificate generation support.

3.2.1 Method to prove possession of private key

All CA private keys are generated by Telia within the system and stored in a Hardware Security Module (HSM).

If the CA or RA does not generate the key pair of the Subject the CA or RA verifies:

1. The electronic signature included in the PKCS #10 Certificate Signing Request (CSR) to be corresponding to the public key of the signers in the CSR

2. Integrity of the signed data

3.2.2 Validation of mailbox authorization or control

Telia CA SHALL NOT delegate verification of domain and/or mailbox authorization or control. Telia CA SHALL verify Applicant’s control or authorization (in case of Mailbox, only accepted authorization is for the email account holder) over domain and/or Mailbox fields referenced in the issued Certificates.

Telia CA employs validation methods approved in Section 3.2.2.4 of the CA/Browers forum TLS Baseline Requirements. Used validation methods are described in this section for supported.

Validation records document the method, and the version number of TLS Baseline Requirements or S/MIME Baseline Requirements used to validate every domain or email address in issued Certificates.

Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation shall have been initiated within the time period specified in the relevant requirement and described in section 4.2.1.1 of this CP/CPS prior to Certificate issuance.

3.2.2.1 Validating authority over mailbox via domain

Telia confirms confirm the Applicant has been authorized by the email account holder to act on the account holder’s behalf by verifying the entity’s control over the domain portion of the Mailbox Address to be used in the Certificate.

Following approved methods in Section 3.2.2.4 of the TLS Baseline Requirements are used to perform this verification.

DCV method	Description of the practice
3.2.2.4.4 Constructed Email to Domain Contact	Telia may use Email addresses listed in BR to check if the Applicant has the right to use the domain. Email message including a unique random value is sent to the address. If the receiver confirms the domain request and know the random value, the domain is approved. Random values are valid for 30 days. Messages may be re-sent in its entirety and if re-sent Telia CA ensures that the message is sent in its original content and unchanged.
3.2.2.4.7 DNS change	Telia may confirm the Applicant's control over FQDN by confirming the presence of a Random Value for either in a DNS CNAME, TXT or CAA record by one of the following methods: 1. an Authorization Domain Name; or 2. an Authorization Domain Name that is prefixed with a label that begins with an underscore character. The Random Value is valid for 30 days and is unique for each receiver.
3.2.2.4.8 IP Address	Telia may confirm the Applicant's control over FQDN by using IP address related to FQDN and IP validation methods described in BR chapter 3.2.2.5. Normal IP validation method is to verify that the applicant or its representative is the owner of the IP in valid IP registry using method 3.2.2.5.2. Email, Fax, SMS, or Postal Mail to IP Address Contact but also method 3.2.2.5.1. Agreed-Upon Change to Website or 3.2.2.5.5. Phone Contact with IP Address Contact may be used. If CSR has IP address, Telia will verify that it isn’t defined as private IP address and then validate it using methods above or using method 3.2.2.5.3. Reverse Address Lookup. This method is NOT ALLOWED to validate Wildcard Domain Names.
3.2.2.4.12 Validating Applicant as a Domain Contact	If the CA is also the Domain Name Registrar, may be used on case-by-case basis upon prior approval of Telia CA Security Board and supervised by assigned Telia CA Security Board member.
3.2.2.4.13 Email to DNS CAA Contact	Following validation procedure is used. - Unique random value is generated to be included in the email sent to the DNS CAA Record Email contact for the Authorization Domain Name selected to validate the Fully Qualified Domain Name. - Unique random value shall be unique for each email. - CAA Resource Record is verified in accordance with RFC 8659 Section 3 - Messages may be re-sent in its entirety and if re-sent Telia CA ensures that the message is sent in its original content and unchanged. - Random value is valid for a maximum lifetime of 30 days. - The CAA contactemail property takes an email address as its parameter. The entire parameter value MUST be a valid email address as defined in RFC 6532, Section 3.2, with no additional padding or structure, or it cannot be used. Each email MAY confirm control of multiple FQDNs, provided that each email address is a DNS CAA Email Contact for each Authorization Domain Name being validated.
3.2.2.4.14 Email to DNS TXT Contact	Following validation procedure is used. - Unique random value is generated to be included in the email sent to the DNS TXT Record Email contact for the Authorization Domain Name selected to validate the Fully Qualified Domain Name. - Unique random value shall be unique for each email. - Messages may be re-sent in its entirety and if re-sent Telia CA ensures that the message is sent in its original content and unchanged. - Random value is valid for a maximum lifetime of 30 days. - The DNS TXT record MUST be placed on the “validation-contactemail” subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid email address as defined in RFC 6532, Section 3.2, with no additional padding or structure, or it cannot be used. Each email MAY confirm control of multiple FQDNs, provided that each email address is a DNS TXT Email Contact for each Authorization Domain Name being validated.
3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact	May be used on case-by-case basis upon prior approval of Telia CA Security Board and supervised by assigned Telia CA Security Board member. In case this method is used, following validation procedure is used under supervision: - Performing direct call to the number defined in the DNS CAA Phone Contact (Record) for the Authorized Domain Name. - Telia CA does not accept calls knowingly transferred or requested to be transferred to the number provided by the said Record. - The Contact MUST be reached directly from the number defined by the Record. - Telia CA SHALL NOT use random values for this validation method. Performed validation is documented and logged in accordance with this CP/CPS.
3.2.2.4.17 Phone Contact with DNS CAA Phone Contact	May be used on case-by-case basis upon prior approval of Telia CA Security Board and supervised by assigned Telia CA Security Board member. In case this method is used, following validation procedure is used under supervision: - Performing direct call to the number defined in the relevant DNS CAA Resource Record (Record) found using algorithm defined in RFC 8659 Section 3. - Telia CA does not accept calls knowingly transferred or requested to be transferred to the number provided by the said Record. - The Contact MUST be reached directly from the number defined by the Record. - Telia CA SHALL NOT use random values for this validation method. Performed validation is documented and logged in accordance with this CP/CPS.
3.2.2.4.18 Agreed-Upon Change to Website v2	Telia may confirm the Applicant’s control over FQDN using random value method described in chapter 3.2.2.4.18 of BR. Telia is using random codes that include 256 bits of entropy. The Random Value is valid for 30 days and is unique for each receiver and for request. The file containing the random value is retrieved using http or https protocol in ports 80 or 443 respectively. The URL used is containing server component using the Authorization Domain Name and URL containing ” /.well-known/pki-validation/_telia_validation_data_file” e.g. http://telia.fi/.well-known/pki-validation/telia_validation_data_file_20200323.txt. For validations performed, redirects are the result of a 301, 302, or 307 HTTP status code response, as defined in RFC 7231, Section 6.4, or a 308 HTTP status code response, as defined in RFC 7538, Section 3. Redirects are the final value of the Location HTTP response header, as defined in RFC 7231, Section 7.1.2.

For purposes of domain validation, the term Applicant includes the Applicant’s Parent Company, Subsidiary Company, or Affiliate.

3.2.2.2 Validating control over mailbox via email

Telia CA confirms the Applicant’s control over each Mailbox Field to be included in a Certificate by sending a Random Value via email and then receiving a confirming response utilizing the Random Value.

Control over each Mailbox Address shall be confirmed using a unique Random Value. The Random Value shalle be sent only to the email address being validated and shalle not be shared in any other way.

The Random Value shalle be unique in each email. The Random Value shall remain valid for use in a confirming response for no more than 24 hours from its creation. The CA MAY specify a shorter validity period for Random Values in its CP and/or CPS.

The Random Value shall be reset upon each instance of the email sent to a Mailbox Address, however all relevant Random Values sent to that Mailbox Address may remain valid for use in a confirming response within the validity period described in this Section. In addition, the Random Value shall be reset upon first use by the user if intended for additional use as an authentication factor following the Mailbox Address verification.

3.2.2.3 Validating applicant as operator of associated mail server(s)

NOT allowed.

3.2.2.4 Validating control over mailbox using ACME extensions

NOT allowed.

3.2.3 Authentication of organization identity

Telia verifies the organization identity of the Applicant through a validation process.

3.2.3.1 Attribute collection of organization identity

Applicable for S/MIME Certificates issued under Organization- and Sponsor-validated profile.

Telia CA or RA SHALL collect and retain evidence supporting the identity attributes for the organization identity and to be included in the Certificate:

1. Country of jurisdiction or registration of the Legal Entity
2. Formal name of the Legal Entity
3. A registered Assumed Name for the Legal Entity (if included in the Subject)
4. An organizational unit of the Legal Entity (if included in the Subject)
5. An address of the Legal Entity (if included in the Subject)
6. Jurisdiction of Incorporation or Registration of the Legal Entity
7. Unique identifier and type of identifier for the Legal Entity

3.2.3.2 Validation of organization identity

Applicable for S/MIME Certificates issued under Organization- and Sponsor-validated profile.

Telia CA verifies the organization identity of a new Subscriber by checking the existence of the company, its legal name, business identity code and other relevant organization information from an official business register maintained by an applicable government agency. The list of applicable trusted registries is disclosed in section 3.2.3.3.

3.2.3.2.1 Verification of name, address, and unique identifier

Subject’s name, registration number (unique identifier) and address components (street, postalcode, locality, country) are verified using trusted registries disclosed in section 3.2.3.3. All attributes must have a successfully verified value.

Telia CA or RA verifies the information by one of the following methods:

1. Information verified from the Reliable Data Source disclosed in 3.2.3.3
2. From attestation verified and confirmed in accordance with 3.2.8

The same documentation or communication MAY be used to verify both the Applicant’s identity and address.

3.2.3.2.2 Verification of assumed name

Telia CA or RA verifies the validity of assumed name from the following sources:

1. Information verified from the Reliable Data Source disclosed in 3.2.3.3
2. From attestation verified and confirmed in accordance with 3.2.8

If option 1. is used, the assumed name’s validity SHALL be verified.

3.2.3.3 Disclosure of verification sources

Telia CA or RA verify organizations unique identifier from the following Telia CA’s verified and authorized sources maintained and/or authorized by relevant government agency:

Registry	Description
Bisnode Infotorg.se (SE)	COM:infotorg.se https://www.infotorg.se This registry is used to check Swedish company details; Account required. This is Web GUI to Bisnode data. Data and sources are same for Bisnode and Infotorg.
YTJ The Business Information System (FI)	Finnish Patent and Registration Office and Finnish Tax Administration register for company information, https://ytj.fi
Bisnode REST API	is trusted in Telia countries (FI, SE, DK, NO, EE, LT) based on data source description from Bisnode (BBC Suite – Data Sources) (FI)

Above list of data sources is considered by Telia CA as Reliable Data Sources as defined by the BR.

3.2.4 Authentication of individual identity

Accepted Individual Identity Attributes for Publicly Trusted S/MIME by Telia CA included in the issued sponsor-validated certificates are:

1. Given name(s) and surname(s), which SHALL be current names of the Individual Applicant

Telia does not issue certificates to private individuals.

3.2.4.1 Attribute collection of individual identity

All identity attribute data is collected from Enterprise RA records for sponsor-validated certificates:

• provided by Enterprise RAs
• contracted by Telia CA and
• accepted as verified evidence of Individual Identities by Telia CA.

Enterprise RAs shall maintain records in accordance with policies and practices required by section 1.3.2 and 8.8 of this CP/CPS and the BR requirements.

3.2.4.2 Validation of individual identity

The Enterprise RA issuing a Sponsor-validated Certificate shall validate all identity attributes of an Individual to be included in the Certificate.

The Enterprise RA may rely upon existing internal records to validate Individual identity.

3.2.5 Non-verified subscriber information

Subject information verified in accordance with the BR and this CP/CPS SHALL be included in the Certificate.

3.2.6 Validation of authority

The Subscriber Organization can agree with Telia to act as a Registration Authority (Enterprise RA) within the Subscriber Organization and to register certificates for the persons or client devices related to the organization and assign responsibilities to others to act in these roles for the organization.

The Subscriber Registration Officer is restricted to register certificates only within their own Organizations (O). Before authorizing the Enterprise RA, Telia CA verifies the organization’s identity as described in section 3.2.3.

Telia verifies that the Subscriber application for a hosted CA has been authorised.

3.2.7 Criteria of interoperation

Telia CA has disclosed all Cross-Certified Subordinate CA Certificates in this CP/CPS and relevant public repositories and databases.

Telia CA shall not issue Cross-Certified Subordinate CA Certificates operated under this CP/CPS to external parties.

3.2.8 Reliability of verification sources

Telia CA verifies at least on annual basis the Reliable Data Sources validity. Validity is verified by Telia CA designated Trusted Role person by requesting and validating official written documentation of the data source(s) from the data source supplier.

Subject information MAY be verified by CA or RA with and official Attestation letter. Attestation letter (and any additional supporting documentation) supporting the fact to be attested is accepted from independent accountant and/or lawyer or from government official.

Attestation SHALL be accepted only in writing and SHALL be verified via Reliable Method of Communication for authenticity by contacting the sender for confirmation.

3.3 Identification and authentication for re-key requests

3.3.1 Identification and authentication for routine re-key

Re-keying requests can be automatically accepted without strong authentication if the subject information remains the same (e.g., one-time-password can be sent to the same mobile phone and/or email address again to re-new the subject’s existing certificate).

If there are changes in the Subject or certificate delivery information the request will be validated in the same way as at initial registration.

3.3.2 Identification and authentication for re-key after revocation

In accordance with 3.3.1.

3.4 Identification and authentication for revocation request

3.4.1 Revocation by Subscriber Organization

Subscriber’s self-service revocation can be activated by the Subject or the Subscriber. The revocation request can be submitted to Telia by the Subject directly or via the Revocation Officer of the Subscriber Organization. In the latter case The Revocation Officer is responsible for the verification of the authenticity and authorisation of therequest.

Telia verifies the identity of the Subject or the Revocation Officer with one-time-password scheme or other reliable method.

In scenarios that Subscriber acts as RA, a revocation shall be done for the followings:

1. Upon suspected or known compromise of the private key
2. Upon suspected or known compromise of the media holding the private key
3. Subject or subscriber information is known to be invalid or re-verification fails
4. When there is an essential error in the certificate
5. When any information in the certificate changes
6. Upon termination of a Subject or when a Subject no longer needs certificates
7. When the certificate is redundant (for example, a duplicate certificate has been issued)
8. Subscriber’s certificate contract with Telia has ended
9. Any other reason that makes the certificate obsolete or threats related keys

Revocation can be performed directly by the Subscriber or a notification for revocation may be given to Telia’s Revocation Service.

3.4.2 Revocation by the Revocation Service of the CA

The Subject, or Subscriber, or Subscriber that acts as RA shall submit a request for certificate revocation to the Revocation Service by telephone or by e-mail. The source of the revocation request will be authenticated based on the S/MIME digital signature or the Revocation Service will make a call back to the Subscriber and asks certain detailed data. The data is compared with the information recorded about the Subject at registration, and if necessary, with information in the agreements made with the Subscriber or with the Subscriber.

If the data match the certificate will be revoked. The Revocation Service is responsible for the verification of the authenticity and authorisation of the request to revoke the certificate.

In certain situations where there is an identified risk of abuse of the private key or when it is obvious that the authorised use of the key is prevented, it may be necessary to revoke the certificate at the request of someone else but the above-mentioned entities. In that case, the verification of the authenticity of the revocation request can require other authentication methods. In cases where reliable verification cannot be immediately performed, the CA may revoke the certificate to reduce risks.

3.4.3 Revocation of CAs

The authorised CA personnel can request revocation of a CA certificate. Authorised Subscriber contact person can request revocation of that Subscriber’s CA certificate. The Policy Management Team in the CA is responsible for the verification of the authenticity and authorisation of the request to revoke the certificate.

Subscriber contact person requesting revocation is authenticated by digital signature, call-back to the Subscriber or by other means that the CA determines necessary to reliably authenticate the person requesting the revocation. The method and information that has been used for verification of the identity of the person requesting revocation, and the revocation request reception time, will be recorded.

Multi-factor authentication mechanisms are used to authenticate users to CA system. Multiple Trusted Roles of CA are required to gain access to revoke a CA certificate in the CA system.

3.4.4 Reinstatement of suspended certificate

Telia CA does not support suspension.

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1 Certificate Application

4.1.1 Who can submit a certificate application

4.1.1.1 CAs

A CA certificate application can be submitted by an authorised Telia CA employee or an authorised representative of the Subscriber that has made an agreement to host their CA at Telia.

4.1.1.2 Subscriber Certificates

Issuing CA	Description
Ericsson NL Individual CA v5 Telia RSA Email CA v6	When a certificate is requested for a subject, it is required that the ordering organization is a Subscriber of Telia with which the Subject has a contractual relation. Certificate request can be submitted by a.) A Subscriber that acts as RA, b.) An employee or other individual contracted by a Customer Organization (Subject), c.) An administrative contact person of a Subscriber Organization

Authorised Telia CA personnel can also submit certificate applications.

4.1.2 Enrolment process and responsibilities

A Subscriber that has agreed to and executed an Agreement with Telia can have a hosted CA at the Telia CA. In the Agreement, the Subscriber is bound to this CPS, the CPS of the subordinate CA being enrolled and other terms and conditions.

During the enrolment process a new CPS is prepared for the subordinate CA unless the new CA can use an existing CPS, in which case the existing CPS is reviewed and required changes are made.

The certificate application is included in the CA hosting agreement. In all cases the final application is made and signed by an authorised Telia CA employee. Telia CA Installation Form document is used for the final application.

Multiple Trusted Roles of CA are required to enrol a new CA certificate based on the data in the final application. Actual enrolment process is documented in Telia CA Operational Documentation.

4.1.2.1 CAs

The application is made and signed by an authorised Telia CA employee. Telia CA Installation Form document is used for such applications.

4.1.2.2 Subscriber Certificates

Issuing CA

Description

Ericsson NL Individual CA v5 Telia RSA Email CA v6

Certificates can be applied for either through the RA office of the CA or directly from the CA system by using the tools supplied by the CA. a.) Subscriber that acts as RA pre-registers the Subject using self-service software provided by Telia and applies for a certificate to the Subject or the Subject can, after pre-registration, initiate the application for a certificate by using the one-time password sent to him/her. The Subject uses the one-time-password to authenticate to the registration tool. The Subscriber or the Subject generates the key pair and submits the certificate request to the CA system containing the certificate information defined by the Subscriber during the pre-registration and the public key, b.) The Subject initiates the enrolment process by submitting a certificate application using self-service software provided by Telia. The Subject generates the key pair and submits the certificate request containing the certificate information. The Subscriber verifies the information in the request and sends the Subject a link to pick up the issued certificate, c.) The self-service software provided by Telia is integrated with the existing authentication solution at the Subscriber site. The subject uses the user credentials in the Subscriber organizations authentication solution to enrol for a certificate (applicable to Ericsson NL Individual CA v4 and Ericsson NL Individual CA v5), d.) Certificate is applied for through the RA office of the CA. The Subscriber or Administrative contact person sends a manually or electronically signed order that contains the necessary information for the certificate there. At the RA office of the CA the signature is checked, the sufficiency of information given for the certificate is examined, and the Subject is pre-registered. The actual certificate request to the CA system can be initiated by the RA office of the CA, or alternatively the necessary instructions and one-time password for the certificate request can be delivered, according to the order, either directly to the Subject or to the Subscriber. The Subscriber Organization is bound to registration policies and Subscriber responsibilities through a certification service agreement with Telia. Subscriber Organization’s Registration Officers also accept Subscriber Responsibilities when they logon to Telia’s self-service application first time

4.2 Certificate application processing

4.2.1 Performing identification and authentication functions

Identification and authentication of Subject and Subscriber information is performed in accordance with the section 3.2.

At least one (1) mailbox field shall be included in the Certificate’s subjectAltName extension: rfc822Name.

4.2.1.1 Reuse of completed validations

Telia CA MAY reuse previously completed validations within following limits:

Validation of mailbox authorization or control	a.) 398 days from previous validation completed in accordance with 3.2.2.1 or 3.2.2.3 b.) Complete validation of control of a mailbox in accordance with 3.2.2.2 SHALL be obtained at earliest 30 days prior of issuance of the Certificate.
Authentication of organization identity	a.) Complete validation of organization identity in accordance with 3.2.3 SHALL be obtained at earliest 825 days prior of issuance of the Certificate b.) Validation of authority in accordance with 3.2.6 SHALL be obtained at earliest 825 days prior issuance of the Certificate or in accordance with agreed time limit in contract between Telia CA and the Applicant.
Authentication of individual identity	a.) Complete validation of Individual identity in accordance with 3.2.2.4 SHALL be obtained at earliest 825 days prior issuance of the Certificate.

Prior validation data and/or document SHALL NOT be used outside the said time limits in this section.

4.2.2 Approval or rejection of certificate applications

Telia will approve a certificate application if it meets the requirements of validation and identification. All other certificate applications will be rejected. The subscriber will be informed on why the certificate application was rejected and on how to proceed to be approved.

For CA’s approvals, PMT approves or rejects CA applications.

4.2.2.1 Certification authority authorization

For S/MIME certificate issuance Telia CA processes DNS CAA records in accordance with Section 4 of the RFC 9495 prior issuance of the certificate.

Recognized authorized CAA domain names for non-ACME in Telia CA are:

• “telia.com”

• “telia.fi”

• “telia.se”

• “trust.telia.com”

Recognized authorized CAA domain names for ACME in Telia CA are:

• “acme.trust.telia.com”

If the certificate certifies more than one email address, then the procedure for each email address being certified is repeated in accordance with this section.

Recognized and supported CAA RR property tags are:

• issuemail

Recognized and supported CAA RR property tag parameters are:

• Critical Flag

• accounturi (only for ACME recognized CAA domains)

During validation Telia queries DNS for the existence of a CAA Resource Record (RR) set. If CAA RRset exists, CAA property tags are processed and if Telia CA is not authorised by the CAA RRset, Telia will not issue the certificate. Telia CA documents prevented issuances when CAA record did not authorize Telia CA to issue certificate.

4.2.2.1.1 DNSSEC validation of CAA records

This section will be effective from March the 15th, 2026 onwards.

Telia shall perform DNSSEC validation back to the IANA DNSSEC root trust anchor on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective.

The DNS resolver used for all DNS queries associated with CAA record lookups performed by the Primary Network Perspective has following capabilities configured and supported:

• perform DNSSEC validation using the algorithm defined in RFC 4035 Section 5; and
• support NSEC3 as defined in RFC 5155; and
• support SHA-2 as defined in RFC 4509 and RFC 5702; and
• properly handle the security concerns enumerated in RFC 6840 Section 4.

Telia CA shall not use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups.

DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) shall not be treated as permission to issue.

Telia CA may perform on all DNS queries associated with CAA record lookups performed by Remote Network Perspectives as part of Multi-Perspective Issuance Corroboration.

4.2.2.2 Multi-perspective issuance corroboration

Effective May 15, 2025, Telia CA SHALL implement multi-perspective issuance corroboration for S/MIME certificates as defined in Section 3.2.2.9 of the TLS Baseline Requirements. Presented timeline presents the latest date from where the requirement is adhered to.

Telia CA MAY choose an earlier date at its own discretion.

4.2.3 Time to process certificate applications

Telia will process the applications for CAs within reasonable time frame. When a certificate is applied for directly from the CA system by the tools provided by the CA, the certificate request is processed automatically by Telia’s RA and CA systems immediately after the request is submitted.

When a certificate is applied for through the RA office of the CA, Telia process the applications within reasonable time frame. There are no specific requirements for the processing time unless otherwise agreed with the Subscriber.

4.3 Certificate issuance

4.3.1 CA actions during certificate issuance

If the certificate application is approved by the Registration Officer, the CA issues the certificate. The certificate is created by the CA according to the information contained in the certificate request.

However, the CA may overwrite some certificate information using pre-defined certificate profile specific standard values.

4.3.2 Notification to Subscriber by the CA of issuance of certificate

4.3.2.1 CA certificate issuance

If the certificate application is approved, the CA generates the root or subordinate CA key pair and issues the certificate. Two trusted Certification Authority Administrators together are required to execute the CA key generation and certificate issuance in the CA system.

The certificate is created by the CA according to the information contained in the final certificate application.

4.3.2.2 Subscriber certificate issuance

Issuing CA	Description
Ericsson NL Individual CA v5	The certificate is available for the Subscriber acting as RA or for the Subject in the registration tool after the issuance.
Telia RSA Email CA v6	The certificate is made available for download in PKCS#12 format by the Subject during the registration process after it has been issued by the CA.

4.4 Certificate acceptance

By accepting a certificate, the Subscriber:

1. Agrees with the continuing responsibilities, obligations and duties required by Telia CA,

2. Agrees to the Telia CA Subscriber Agreement and Terms of Use,

3. Represents and warrants that no unauthorised access to the private key associated with the certificate is allowed,

4. Represents and warrants that the provided information during the registration process is truthful and accurate, and

5. Review and verify the certificate contents for accuracy, completeness and the certificate is not damaged or corrupted. Note: When a certificate is inaccurate, damaged, or corrupted (violation of item V above), the Subscriber should inform the CA.

4.4.1 Conduct constituting certificate acceptance

The Subscriber is considered to have accepted the certificate when:

• The Subscriber start using the certificate’s key pair, or

• One calendar month is passed from the certificate issuance date.

4.4.2 Publication of the certificate by the CA

CA certificates are published in the CA repository in accordance with the section 2.1.3. Telia will not publish subscriber certificates to a publicly available repository if not agreed upon with the Subscriber Organization.

4.4.3 Notification of certificate issuance by the CA to other entities

All publicly trusted CA certificates are published to CCADB database at https://ccadb.force.com within 7 days of issuance.

There is no external notifications related to the issuance process of End-Entity certificates.

4.5 Key pair and certificate usage

4.5.1 Subscriber private key and certificate usage

The subscriber shall only use certificates and their associated key pairs for the purposes identified in this CPS and in applicable agreements with Telia. Issued certificates contain information which defines suitable areas of application for the certificate and its associated keys. Area of application labelling takes place in accordance with X.509 and chapter 7 of this CPS.

For more information regarding appropriate Subscriber key usage see sections 1.4.1 and 6.1.7.

The Subscriber shall protect the Subject private key from unauthorised use. If the private key is compromised the Subscriber shall discontinue the use of the Subject private key immediately and permanently and request for the revocation of the certificate.

4.5.2 Relying party public key and certificate usage

Prior to accepting a Telia certificate, a Relying Party is responsible to:

1. Verify that the certificate is appropriate for the intended use

2. Check the validity of the certificate, e.g., verify the validity dates and the validity of the certificate and issuance signatures

3. Verify from a valid CRL or other certificate status service provided by the CA that the certificate has not been revoked or suspended. If certificate status cannot be verified due to system failure or similar, the certificates shall not be accepted

4.6 Certificate renewal

Certificate renewal is the re-issuance of a certificate with a new validity date using the same public key corresponding to the same private key. Normally a new key pair is generated when a certificate is renewed and Telia prefers that the certificates are re-keyed instead of renewing them using the existing key pair. However, it is possible that Subscriber uses existing key pairs instead of generating new public and private keys. Certificate renewal requests are processed as certificate re-keys as described in section 4.7.

4.7 Certificate re-key

Certificate re-key is the re-issuance of a certificate using new public and private keys but same subject and SAN values as before.

4.7.1 Circumstance for certificate re-key

When the validity time of a certificate is about to end, the certificate can be re-keyed. Also, technical problems in certificate installation or in certificate storage may trigger re-keying.

4.7.2 Who may request certification of a new public key

Re-key may be requested by the same persons as the initial certificate application as described in section 4.1.1. If the Subject has technical problems with the certificate or he/she has lost the certificate, the Subject may also request a new certificate from Telia’s Subscriber Service.

4.7.3 Processing certificate re-keying requests

Ericsson NL Individual CA v5	If the certificate re-key is started by the acting as the RA role, it is his/her responsibility to ensure that there are no obstacles to the re-key. If there are changes in the Subject information or in the certificate delivery information those shall be checked in the same way as at initial registration. A re-keyed certificate is issued and delivered in the same way as the initial certificate as described in section 4.1 – 4.4. If the certificate re-key is processed by the Customer Service of the CA or other authorised CA personnel, they ensure that the original usage purpose for the certificate still exists. Then they use the information from the initial certificate request authorised by the Registration Officer and deliver the one-time password to the Subject using the existing contact information stored in the registration system. The Subject can then use the one-time password to initiate the application for a certificate.
Telia RSA Email CA v6	Re-key is processed in the same way as the initial certificate application as described in section 4.1 – 4.4

4.7.4 Notification of new certificate issuance to subscriber

Subscriber is notified in the same ways when the certificate is issued first time as described in section 4.3.2.

4.7.5 Conduct constituting acceptance of a re-keyed certificate

Conduct constituting acceptance of a re-keyed certificate is described in section 4.4.1.

4.7.6 Publication of the re-keyed certificate by the CA

Re-keyed certificates are published like initial certificates as described in section 4.4.2.

4.7.7 Notification of certificate issuance by the CA to other entities

Certificate re-key notifications are generated like initial certificate notifications as described in section 4.4.3.

4.8 Certificate modification

Certificate modification is the re-issuance of the certificate due to changes in the certificate information other than the validity time (certificate renewal) or Subscriber’s public key (certificate re-key). Certificate modification requests are processed as initial certificate requests as described in sections 4.1 – 4.4.

Certificate subject or extension modification is possible within certificate renewal process which is covered in section 4.6.

4.9 Certificate revocation and suspension

Telia CA supports Certificate Revocation. Certificate suspension is not used.

When a Certificate is Revoked, it is marked as revoked by having its serial number added to the CRL to indicate its status as revoked. In addition, the OCSP database is updated, and operational period of that Certificate is immediately considered terminated.

4.9.1 Circumstances for revocation

4.9.1.1 Reasons for Revocing a Subscriber Certificate

Telia CA will revoke a Subscriber certificate within 24 hours if one or more of the following occurs:

1. The Subscriber requests in writing that Telia CA revoke the Certificate

2. The Subscriber notifies Telia CA that the original certificate request was not authorised and does not retroactively grant authorisation

3. Telia CA obtains evidence that the Subscriber’s private key corresponding to the public key in the certificate suffered a key compromise

4. Telia CA obtains evidence that the validation of domain authorisation or control for any Fully Qualified Domain Name (FQDN) or IP address in the Certificate should not be relied upon

5. Telia CA is made aware of a demonstrated or proven method that exposes the Subscriber’s private key to compromise, methods have been developed that can easily calculate it based on the public key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence that the specific method used to generate the private key was flawed

Telia CA will revoke a Subscriber certificate within 5 days if one or more of the following occurs:

6. The Certificate no longer complies with the requirements of Section 6.1.5 and Section 6.1.6

7. The CA obtains evidence that the Certificate was misused

8. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use

9. The CA is made aware of any circumstance indicating that use of a Fully Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant’s right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name)

10. The CA is made aware of a material change in the information contained in the Certificate

11. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the applicable CP/CPS

12. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate

13. The CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;

14. Revocation is required by the applicable CP/CPS

15. The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed.

4.9.1.2 Reasons for Revoking a Subordinate CA Certificate

Telia CA will revoke a Subordinate CA certificate within seven (7) days if one or more of the following occurs:

1. The Subordinate CA requests revocation by trustworthy means of communication (written request, phone call etc.)

2. The Subordinate CA notifies the Telia CA that the original certificate request was not authorised and does not retroactively grant authorisation

3. The Telia CA obtains evidence that the Subordinate CA’s private key corresponding to the public key in the certificate suffered a key compromise or no longer complies with the Baseline Requirements of Sections 6.1.5 and 6.1.6

4. Telia CA obtains evidence that the certificate was misused

5. Telia CA is made aware that the certificate was not issued in accordance with, or that Subordinate CA has not complied with this document or the applicable CPS

6. Telia CA determines that any of the information appearing in the certificate is inaccurate or misleading

7. Telia CA or Subordinate CA ceases operations for any reason and has not made arrangements with another CA to provide revocation support for the certificate

8. Telia CA’s or Subordinate CA’s right to issue certificates under the Baseline Requirements expires or is revoked or terminated, unless the Telia CA has made arrangements with another CA to continue maintaining the CRL/OCSP Repository

9. Revocation is required by the Telia CA’s CPS

4.9.2 Who can request revocation

The revocation of a certificate can be requested by:

1. A Subject whose name the certificate is issued under

2. A Subscriber or Subscriber that acts as RA that has made an application for a certificate on behalf of an organization, device or application

3. Personnel of Telia CA

4. An authorised representative of the Subscriber hosting their CA at Telia

5. Subscribers, Relying Parties, Application Software Suppliers, and other third parties MAY submit Certificate Problem Reports informing the Issuing CA of reasonable cause to revoke a Certificate.

4.9.3 Procedure for revocation request

For CA revocation, Telia CA identifies and authenticates the originator of a revocation request according to section 3.4. The PMT approves revocation requests. The certificate is permanently revoked after the approval.

The Subject, and where applicable the Subscriber, of a revoked certificate, where possible, will be informed of the change of status of the certificate. When making a revocation request as above, Telia’s CA system checks that the digital signature on the revocation request is valid and that the person signing the revocation request is authorised to do so. If both these criteria are met, the certificate in question is revoked.

A revocation request may be received by Telia in one of the following ways:

1. Subscriber acting as RA makes the revocation request using the administration interface

2. The Subject makes the revocation request using a self-administration or re-enrolment interface

3. Revocation may be requested by contacting Telia CA’s Revocation Service by telephone or via online channel (see 1.5.2)

If the revocation request cannot be carried out in accordance with a. or b., the Subscriber acting as RA, or the Subject may contact Telia Revocation Service by telephone or email and make a revocation request. Authorised Telia revocation staff, then authenticates the identity of the originator of a revocation request according to section 3.4 and makes the revocation request using Telia’s CA system.

When making a revocation request as above, Telia’s system checks that the person making revocation request is authorised to do so and after that the certificate in question is revoked.

4.9.4 Revocation request grace period

The CA is available for revocation requests 24 hours per day, 7 days per week.

When a reason for the revocation of a certificate appears, the Subject or Subscriber shall as soon as possible inform the Revocation Service directly or the Subscriber that acts as the RA. Also, the Registration Officer shall revoke the certificate using the administration interface or inform Telia’s Revocation Service as soon as possible, when a reason for the revocation of a certificate comes to his/her notice.

The CA shall not be responsible for the damage caused by illicit use of the Subject’s private key. The CA shall be responsible for the publication of the revocation information on the CRL according to the principles given in this CPS.

4.9.5 Time within which CA must process the revocation request

Telia CA processes revocation requests within reasonable time frame or at least within 24 hours.

The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation shall not exceed the time frame set forth in Section 4.9.1.1.

4.9.6 Revocation checking requirement for relying parties

Prior to using a certificate, it is the Relying Party’s responsibility to check the status of all certificates in the certificate validation chain against the current CRL’s or on-line OCSP.

A certificate cannot be reasonably relied on if the Relying Party does not diligently follow the certificate status checking procedures denoted below:

• A Relying Party shall ensure him-/herself of the authenticity and integrity of the CRLs or on-line certificate status responses by checking the digital signature and the certification path related to it

• The Relying Party shall also check the validity period of the CRL and OCSP response in order to make sure that the information in the CRL or OCSP response is up to date

• Certificates may be stored locally in the Relying Party’s system, but the prevailing revocation status of each of those certificates shall be checked before use

• If valid certificate status information cannot be obtained because of a system or service failure, not a single certificate must be trusted. The acceptance of a certificate in violation of this condition befalls at the Relying Party’s own risk

The Relying Party may acquire the checking of the CRLs as a service that shall follow the certificate status checking procedures denoted above.

4.9.7 CRL issuance frequency

The CRL Revocation Status Service is implemented by publishing CRLs that are digitally signed by the CA and publicly available. The following rules are enforced:

For the CA’s:

1. A new CRL is published at intervals of not more than twelve months

2. A new CRL is published within 24 hours after revoking a Subordinate CA Certificate

3. The validity time of every CRL is one year

For subscriber certificates:

1. A new CRL is published at intervals of not more than twenty-four (24) hours

2. The validity time of a CRL is forty-eight (48) hours

3. The publishing intervals and validity time may also be agreed upon with Telia’s Subscriber

There may be several valid CRLs available at the same time. The one of those, which has been published as the latest, contains the most real-time information.

4.9.8 Maximum latency for CRLs

No stipulation.

4.9.9 On-line revocation/status checking availability

Telia may provide on-line revocation status checking via the OCSP protocol.

When provided, OCSP responses SHALL conform to RFC 6960 and/or RFC 5019 and via HTTP GET method.

OCSP responses SHALL be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked.

The OCSP signing Certificate SHALL contain the ocspSigning EKU (1.3.6.1.5.5.7.3.9) and an extension of type id-pkix-ocsp-nocheck, as defined by RFC 6960.

4.9.10 On-line revocation checking requirements

All OCSP responses will be signed.

All responses will be signed by a private key corresponding to a public key certified by the CA on which the OCSP request is made.

The OCSP service is using near-real-time CA database information. The OCSP responder may use the previous status value for a certificate if it is fresher than two hours old (refresh time). In rare circumstances where the connection between OCSP and CA is broken the status information may be up to 48 hours old (grace period).

The validity interval of an OCSP response is the difference in time between the thisUpdate and nextUpdate field, inclusive. For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds.

4.9.10.1 Status of Subscriber Certificates

For the status of subscriber certificates following applies:

• OCSP responses have validity interval greater than or equal to eight hours.

• OCSP responses have validity interval less than or equal to ten days.

• For OCSP responses with validity intervals less than sixteen hours, the information provided via an Online Certificate Status Protocol, will be one-half of the validity period before the nextUpdate.

• For OCSP responses with validity intervals greater than or equal to sixteen hours, the information provided via an Online Certificate Status Protocol, shall be at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate.

4.9.10.2 Status of Subordinate CA Certificates

For the status of subordinate CA certificates following applies:

The CA SHALL update information provided via an Online Certificate Status Protocol

• At least every twelve months.

• Within 24 hours after revoking a Subordinate CA Certificate.

4.9.10.3 Other information

OCSP responder will respond with an “unknown” status for certificate status request for a certificate serial number that is “unused”, thus do not exist in the CA database.

For Telia CA OCSP service, a certificate serial number within an OCSP request is one of the following three options:

1. “assigned” if a Certificate with that serial number has been issued by the Issuing CA, using any current or previous key associated with that CA subject.

2. “reserved” if a Precertificate [RFC6962] with that serial number has been issued by the Issuing CA.

3. “unused” if neither of the previous conditions are met.

4.9.11 Other forms of revocation advertisements available

Not applicable.

4.9.12 Special requirements regarding key compromise

In case of CA private key compromise, the procedures defined in section 5.7.3 are followed.

Telia CA uses commercially reasonable efforts to notify potential Relying Parties if it discovers or suspects the compromise of a Private Key. Revocation reason code “key compromise” is used in such case.

The key compromise cases shall be reported to Telia CA instantly by Subscriber or any other parties or participants. The report shall include supporting information such as the CSR that was signed by the compromised private key, the actual private key or a valid email address that can be used for further communication regarding the revocation of the corresponding certificate compromised key.

4.9.13 Circumstances for suspension

Telia CA does not support suspension.

4.9.14 Who can request suspension

Telia CA does not support suspension.

4.9.15 Procedure for suspension request

Telia CA does not support suspension.

4.9.16 Limits on suspension period

Telia CA does not support suspension.

4.10 Certificate status services

4.10.1 Operational characteristics

Revocation information on a CRL or OCSP Response are not removed until after the expiry date of revoked certificates.

CRLs are digitally signed using the CA’s private key.

OCSP response is digitally signed by the OCSP response certificates.

4.10.2 Service availability

The certificate status services are available 24 hours per day, 7 days per week.

4.10.3 Optional features

Relying parties may decide if they are using OCSP or CRL to verify certificate status.

4.11. End of subscription

The end of a subscription because of no longer requiring the service, compromise or breach of contract result in the termination of the CA as described in section 5.8.

The end of a subscription because of no longer requiring the service, compromise, or termination of employment (voluntary or imposed) will result in the immediate revocation of the certificate and the publishing of a CRL or other certificate status verification system.

4.12 Key escrow and recovery

4.12.1 Key escrow and recovery policy and practices

Key escrow is an arrangement in which the keys needed to decrypt encrypted data are held in escrow so that, under certain circumstances, an authorised third party may gain access to those keys¹.

CA private keys or Subscriber’s digital signature private keys will not be escrowed.

A Subscriber’s confidentiality private keys will not be escrowed but Telia may keep a backup of the keys if agreed between Telia and the Subscriber.

The keys are protected in an encrypted form and are protected at a level no lower than stipulated for the primary versions of the keys. The decryption key used to decrypt the key backups is stored in an HSM and the key backups are saved for a period that is agreed with the Subscriber.

A private key may be recovered for two separate reasons:

1. The hard disc, the Smart Card or equivalent that holds the Subscriber’s private key is corrupted and the Subscriber needs to make a recovery of his key. The process of authenticating the Subscriber is the same as at the initial certificate issuance. When a private key has recovered the certificate for the corresponding public key is automatically revoked, a new key pair is created, and a new certificate is issued
   
2. The Subscriber is for some reason prevented from using his private key (the Subscriber may, for instance, be deceased, injured or has left the organization) and Subscriber’s Organization needs to decrypt data encrypted by the Subscriber. The process of such key recovery involves at least two (2) persons from the Subscribers’ organization or at least two (2) persons from the CA organization where all are authenticated by certificates. When a private key has recovered the certificate for the corresponding public key is automatically revoked For short-lived personal certificates there will be no key-escrow or recovery.

4.12.2 Session key encapsulation and recovery policy and practices

Not applicable.

5. FACILITIES, MANAGEMENT, AND OPERATIONAL CONTROLS

Telia CA has implemented continuously maintained Security Program in accordance with Telia Company policies, processes, and procedures including built-in Risk Assessment program.

Telia CA’s Security Program is designed to address (but not necessarily limited to):

• Protection of the confidentiality, integrity, and availability of Certificate Data and Certificate Management Processes.

• Protection against anticipated threats or hazards to the confidentiality, integrity, and availability of the Certificate Data and Certificate Management Processes.

• Protection against unauthorized or unlawful access, use, disclosure, alteration, or destruction of any Certificate Data or Certificate Management Processes.

• Protection against accidental loss or destruction of, or damage to, any Certificate Data or Certificate Management Processes

• Compliance with all other security requirements applicable to the CA by law.

• Risk assessment program

  • to identify foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes.
  • to assess the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes
  • to assess the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats. Based on the Risk Assessment, Telia CA develop, implement, and maintain a security plan consisting of security procedures, measures, and products designed to achieve the objectives set forth above and to manage and control the risks identified during the Risk Assessment, commensurate with the sensitivity of the Certificate Data and Certificate Management Processes.

The security plan includes administrative, organizational, technical, and physical safeguards appropriate to the sensitivity of the Certificate Data and Certificate Management Processes.

Within the security plan Telia CA considers and take account of then-available technology and the cost of implementing the specific measures and implement a reasonable level of security appropriate to the harm that might result from a breach of security and the nature of the data to be protected.

Telia CA incorporates the CA/Browser Forum’s Network and Certificate System Security Requirements by reference as if fully set forth herein².

5.1 Physical controls

5.1.1 Site location and construction

Telia’s CA and RA operations are conducted within Telia’s premises in Finland and Sweden.

All Telia CA and RA operations are conducted within a physically protected environment designed to deter, prevent, and detect covert or overt penetration.

5.1.1.1 CA Site location and construction

The premises where central CA functions take place are physically located in a highly secure server rooms dedicated for CA operations. The physical protection of which corresponds at least with the requirements for “priority 1 premises” defined in the regulation on priority rating, redundancy, power supply and physical protection of communications networks and services (TRAFICOM/54045/03.04.05.00/2020) issued by TRAFICOM (Finnish Transport and Communications Agency). Within these server rooms, key components are locked in separate, freestanding security cabinets.

Telia CA operates two distinct sites in Finland. In addition to what is said above, one (1) of the facilities is meeting structural specifications of KATAKRI Level III for Secure Areas.

The server rooms, which are locked and alarmed, are in secure buildings, which are also locked and alarmed. These are protected jointly by using active monitoring.

5.1.1.2 RA Site location and construction

The premises where central RA functions take place are physically located in highly secure server rooms.

Within these server rooms, key components are locked in separate, freestanding security cabinets. The server rooms, which are locked and alarmed, are in secure buildings, which are also locked and alarmed. These are protected jointly by using active monitoring.

1. Identification on application of key holders who are present in person

2. Issuing keys and codes

3. Identifying key holders and ownership of the correct private key on electronic application

4. Electronic registration of key holders

5. Revocation service for revoking certificates

Functions in accordance with a. do not involve any access to the central RA system. This environment therefore has no specific security provisions in terms of physical security.

Functions in accordance with b. to e. are carried out in well controlled office environments where access is restricted to authorised personnel.

5.1.2 Physical access

For security reasons, detailed information on security procedures for physical access to the premises is not publicly available but is described in the Telia Operational Documentation. The security procedures are described in separate documentations belonging to the Telia CA Services.

The physical locations, sites and premises are under 24/7 surveillance and monitoring by on call site security.

Authorized Trusted Role personnel may access CA and RA sites and servers unescorted based on pre-approved and authorized access lists. Unauthorized visitors will be escorted by authorized personnel and supervised during their work.

Site access is logged and monitored. Access logs are inspected at least quarterly by qualified personnel. The inspection documentation is retained for at least a one-year period to support audit requirements.

Access control and monitoring systems are secured by uninterruptible power supply systems (UPS).

UPS system undergoes annual inspection and disaster recovery testing by site operator, and the inspection documentation is retained for at least a one-year period.

5.1.2.1 CA Site Physical access

Telia CA facilities are protected at least five (5) tiers of distinctive physical security layers where the CA systems and other important CA devices have been placed in a security vault. Protection and controls are progressively restrictive from tier to tier.

The detailed implementation of controls and mechanisms applied for access control and monitoring is classified as confidential information and documented in separate Telia CA documentation and made available on need-to-know basis only.

5.1.2.2 RA Site Physical access

The Telia RA systems are protected at least four (4) tiers of distinctive physical security layers. Protection and controls are progressively restrictive from tier to tier. The detailed implementation of controls and mechanisms applied for access control and monitoring is classified as confidential information and documented in separate Telia CA documentation and made available on need-to-know basis only.

5.1.3 Power and air conditioning

Telia locations are equipped with required establishments as expressed in section 5.1.1.1 for structural site requirement specification.

5.1.4 Water exposures

Telia locations are equipped with required establishments as expressed in section 5.1.1.1 for structural site requirement specification.

5.1.5 Fire prevention and protection

Telia locations are equipped with required establishments as expressed in section 5.1.1.1 for structural site requirement specification.

5.1.6 Media storage

All media containing production software and data, audit, archive, or backup information is stored within the Telia facilities or in a secure off-site storage premises with appropriate physical and logical access controls designed to limit access to authorised 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 before disposal. Media used to collect or transmit sensitive information are rendered unreadable before disposal. Cryptographic devices are physically destroyed or erased in accordance with Telia CA’s guideline for secure material decommission. Other waste is disposed of in accordance with Telia’s normal waste disposal requirements.

5.1.8 Off-site backup

Telia performs daily routine backups of critical system data, audit log data, and other sensitive information. The backups are either daily transported over a secure channel or periodically moved physically to an off-site storage facility.

5.2 Procedural controls

Telia is responsible for all procedures and circumstances defined in this section. This includes everything from production and logistics to the administration of the entire process.

Critical CA and RA operations is prohibited from being performed at distance over networks and must be performed locally at the CA and RA sites.

5.2.1 Trusted roles

Trusted Roles include all employees, contractors, and consultants that have access to or control authentication, cryptographic operations and information that may materially affect:

1. The administration of CA private keys and RA system private keys

2. Configurations of the CA and central RA systems

3. The validation of information in Certificate Applications

4. The acceptance, rejection, or other processing of Certificate Applications, revocation requests, or renewal requests, or enrolment information

5. The issuance, or revocation of Certificates

6. The handling of Subscriber information or requests

Trusted Roles include, but are not limited to:

1. Customer service personnel

2. Cryptographic business operations personnel

3. Security personnel

4. System administration personnel

5. Designated engineering personnel

6. Executives that are designated to manage infrastructural trustworthiness

Telia considers the categories of personnel identified in this section as Trusted Roles having a Trusted Role. Persons appointed to Trusted Roles by appropriate management authorization, person adopting the Trusted Role must successfully complete the screening requirements of section 5.3 before the Trusted Role is assigned to the person.

Examples of roles defined for CA and RA operations and maintenance are:

5.2.1.1 Certification Authority Administrator (CAA)

Administrative production/operational staff for the CA and RA systems.

Typical duties which may be administered by the CAA include:

1. creating CA certificates

2. personalising cards

3. generating CA and central RA keys

4. configuration of CA and RA applications

5. generating revocation lists

6. Checking the certificate issue log

5.2.1.2 System Administrator (SA)

Technical production/operational staff for the CA and RA systems.

Typical duties which may be administered by the SA include:

1. installations of hardware and software

2. system maintenance

3. changing of backup media

5.2.1.3 Security Manager

Overall responsibility for the security and compliance of the Telia CA Service.

5.2.1.4 Registration Officer

RA Office and Customer Service staff of the CA. Subscriber RA’s Registration Officers are not Trusted Roles.

Typical duties of the Registration Officer include processing and approving certificate applications and submitting certificate requests to the CA system that issues and signs the certificates. Registration Officers also create new Subscriber accounts, privileges, and values to enable Telia’s self-service software for Subscribers.

Telia has chosen to divide the responsibility for the above roles into sub-roles to increase security.

5.2.2 Number of persons required per task

Telia maintains a policy and rigorous control procedures to ensure segregation of duties based on job responsibilities. The most sensitive tasks, such as access to and management of CA and central RA cryptographic modules and associated key material, require presence of and/or actions by multiple authorized Trusted Role individuals (Dual Control).

These internal control procedures are designed to ensure that at a minimum, two individuals are required to have either physical or logical access to the device. Access to CA and central RA cryptographic hardware is enforced by Dual Control throughout its lifecycle, from incoming receipt and inspection to final logical and/or physical destruction. Once a module is activated with operational keys, further access controls are invoked to maintain segregation of duties and/or Dual Control over both physical and logical access to the device. Requirements for CA private key activation data is specified in section 6.2.2.

Physical and operational system access to the central CA and RA servers require the participation of at least 2 Trusted Roles that works in conjunction. Either persons work physically together, or the other Trusted Roles is involved via following security controls:

1. Each administrative login or physical access to critical servers or environments is causing alarm to be inspected by security supervisors. If alarm is caused by a security supervisor only another security supervisor can inspect and accept the alarm.

2. Each operation and command entered by operator is logged on the separate log server.

3. All operational remote access to critical systems is done only via secure management hosts.

4. Root/admin privilege of log and management hosts are guarded by persons who have no root access to CA servers. If maintenance to log/maintenance server is required, the normal system operators may get temporary root access from the root guards.

5. Critical files and directories are monitored by checksum tests, so they are not modified during operational access. Security supervisors get alarm if modifications are done. If alarm is caused by a security supervisor only another security supervisor can inspect and accept the alarm

6. Segregation of duties separates the role to install new CA and RA software from the role to activate CA and RA keys and vice versa. CAA role may have both rights but there are several compensating processes such as regular log comparison and configuration check and login alarm to verify that there doesn’t exist any non-controlled processes or certificates.

Other requirements in terms of the presence of people when carrying out other tasks involving CA and RA operations are detailed in the Telia CA Operational Documentation.

The Trusted roles in section 5.2.1 are fulfilled by at least one person each. Those working in the role of CA System Administrator or Registration Officer do not simultaneously work in any of the other roles involving the system.

5.2.3 Identification and authentication for each role

Person appointed and authorized to a Trusted Role by Telia CA and appropriate manager, person’s identity is verified during the recruitment process by in presence verification of the person and corresponding legally acceptable identity certificate (e.g., passport, national identity card or equivalent) by the recruiter. List of nationally acceptable identity certificates is verified by the recruiter.

In addition to above identity verification, each person is further cleared by background checking procedures described in section 5.3.1 before any of the following may be granted.

1. Included in the access list for the CA and RA sites

2. Included in the access list for physical access to the CA and RA system

3. Given a certificate for the performance of their CA or RA role

4. Given a user account on the CA or RA system Each of these certificates and accounts shall be:

   1. Personal and directly attributable to the Trusted Role

   2. Restricted to actions authorised by the Trusted Role in use of CA and RA software, servers and operating systems, physical access, and procedural controls

Identification of roles in the CA and RA systems takes place as follows:

Identification of SA roles take place within the operating system in the CA and RA systems. Identification of the CAA roles (where applicable) take place within the CA system applications and is based on strong authentication using personal operator smart cards.

Identification of the RA roles takes place within the CA and RA system applications, and it is based on strong authentication either using personal operator cards or other two factor authentication mechanisms depending on the policy requirements of the applicable CA.

5.2.4 Roles requiring separation of duties

Telia maintains a policy and rigorous control procedures to ensure a separation of duties for critical CA and RA functions to prevent one person from maliciously using the CA or RA system without detection. Complete documentation of all roles and what roles are allowed for a single person can be found from Telia CA Operational Documentation.

5.3 Personnel controls

5.3.1 Qualifications, experience, and clearance requirements

Persons selected and designated to any of the Trusted Roles defined in section 5.2.1 shall meet set qualifications for the position as seen required by Telia. Qualifications include (but are not limited to) prior work experience, educational qualifications and general trustworthiness of the candidate in relation to the position. Same selection criterion applies to internal employees, contingent workers and external resources.

Qualifications and selection criterion may vary on country by country basis in Telia’s geographical footprint. All qualifications are evaluated and verified in accordance of the local laws applicable to the candidate selection process.

Segregation of Duties (SoD) is applied over Trusted Roles by separately documented SoD rules defined in Telia CA’s internal policies and guidelines. Primary objective is that segregation adheres to “least privilege” and “approver and executor are distinct roles or dual control must be applied”.

In addition to above, all persons designated to any Trusted Role must be cleared by national background check and security clearance performed by designated government office or agency and described in section 5.3.2.

Telia HR may request for applicable certification documentation to be presented by the person being considered to a Trusted Role as deemed necessary by Telia HR on case by case basis.

5.3.2 Background check procedures

Telia conducts background checks for each Trusted Role candidate as described in this section. Background check and security clearance shall be performed by designated government office or agency in accordance with national laws and in relation to requirements specific to the Trusted Role.

Information considered in the background check and security clearance is dependent on the national regulations and may vary between the countries where Telia CA operates.

Background clearance may include one or more of the following (additional checks and verifications may be included from time to time as seen necessary by Telia) verifications:

• Confirmation of previous employment

• Check of professional reference

• Search of criminal records (local, state, or provincial, and national)

• Check of credit/financial records

• Search of driver’s license records

• National security clearance check

Background checks are repeated periodically for Trusted Role personnel, in accordance with national laws and Telia’s corporate policies.

The outcome of background check is considered on grounds for accepting or rejecting candidate for a Trusted Role, generally including the following (but not necessarily limted to):

• Misrepresentations made by the candidate or Trusted Role

• Highly unfavourable or unreliable personal references

• Possible criminal background

• Indications of a lack of financial responsibility

Outcome and reports are evaluated by human resources and security personnel, who determine the appropriate course of action considering the full impact uncovered by the background check.

Any personal data and personally identifiable information (PII) disclosed by the background check is subject to the applicable federal, state, and local laws and considered as confidential information on as need to know basis.

5.3.3 Training requirements

Telia provides its personnel with courses and training needed for personnel to perform their job responsibilities competently and satisfactorily. Telia periodically reviews and enhances its training programs as deemed necessary.

Training programs consist of general trainings and tailored trainings on role and responsibility basis, including but not limited to the following:

• Basic PKI concepts

• Telia CA’s operational requirements and policies (e.g. CP/CPS, internal guidelines and instructions)

• Telia security and operational policies and procedures

• Use and operation of deployed hardware and software

• Incident and Compromise reporting and handling

• Common security and vulnerability awareness trainings and updates

• Global PKI community updates and trainings (e.g. CA/Browser forum updates)

• Role and occupation dependent training (e.g. Registration Officer)

• Individually tailored training programs

All personnel responsible for performance of certificate data validation (Validation Specialists in Baseline Requirements) are required on annual basis to complete and pass an exam to show proof of their validation skills in relation to this CP/CPS and consequently underlying Baseline Requirements.

5.3.4 Retraining frequency and requirements

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

5.3.5 Job rotation frequency and sequence

Not applicable.

5.3.6 Sanctions for unauthorised actions

All employees and external resources working for Telia are informed about their obligation to report details immediately to superior, Group Security, Corporate Internal Audit on suspected security events, criminal activity, or fraud acts. Appropriate disciplinary actions are taken for unauthorised actions or other violations of Telia policies and procedures.

Disciplinary actions may include warning, role change or termination of employment and are dependent on the frequency and severity of the unauthorised actions.

5.3.7 Independent contractor requirements

Independent contractors or external consultants may be designated to a Trusted Role. External persons are subject to the same qualifications and background controls as Telia employed personnel prior designation to a Trusted Role.

Independent contractors and consultants who have not completed the background check procedures specified in section 5.3.2 may only access Telia’s secure facilities escorted and directly supervised by authorized person in applicable Trusted Role.

5.3.8 Documentation supplied to personnel

Telia personnel involved in the operation of Telia CA Services will be provided with required documentation needed to perform their duties.

5.4 Audit logging procedures

Telia CA and its Delegated Third Parties deploy auditing, monitoring, and logging system that continuously monitors, detects, and alerts designated personnel of any modification to Certificate Systems, Issuing Systems, Certificate Management Systems, Security Support Systems, and Front‐End / Internal‐Support Systems.

If deployed system cannot automatically detect and record an event, manual procedures are implemented to ensure required events are recorded.

5.4.1 Types of events recorded

CA and RA certificate and key lifecycle events, including

1. Key generation, backup, storage, recovery, archival, and destruction
2. Certificate requests, renewal, and re-key requests, and revocation
3. Approval and rejection of certificate requests
4. Cryptographic device lifecycle management events
5. Generation of Certificate Revocation Lists
6. Signing of OCSP Responses (as described in Section 4.9 and Section 4.10)
7. Introduction of new Certificate Profiles and retirement of existing Certificate Profiles

Subscriber Certificate lifecycle management events, including

1. Certificate requests, renewal, and re-key requests, and revocation
2. All verification activities stipulated in these Requirements and the CA’s Certification Practice Statement
3. Approval and rejection of certificate requests
4. Issuance of Certificates
5. Generation of Certificate Revocation Lists
6. Signing of OCSP Responses (as described in Section 4.9 and Section 4.10)
7. Date, time, phone number used, persons spoken to, and end results of verification telephone calls
8. The type(s) of identification document(s) presented by the Certificate Applicant
9. Storage location of copies of applications and identification documents
10. Identity of entity accepting the application
11. Method used to validate organization and individual identity and authority
12. Information concerning the person requesting revocation
13. Method of verifying the identity of the person requesting revocation
14. Revocation request reception time
15. Information concerning the certificate to be revoked

Security events, including

1. Successful and unsuccessful PKI system access attempts
2. PKI and security system actions performed
3. Security profile changes
4. Installation, update, and removal of software on a Certificate System
5. System crashes, hardware failures, and other anomalies
6. Firewall and router activities
7. Entries to and exits from the CA facility

All Log entries include the following elements:

1. Date and time of event
2. Identity of the person making the journal record
3. Description of the event

All records are made available for external auditing performed by qualified auditors as proof of Telia’s adherence to applicable requirements, policies, and practices attributable to Telia.

5.4.2 Frequency of processing log

In the CA system the audit logs are reviewed at least monthly to check for any unauthorised activity. Audit log reviews include a verification that the log has not been tampered with, a brief inspection of all log entries, and a more thorough investigation of any alerts or irregularities in the logs. Actions taken based on audit log reviews are also documented.

In the RA systems the audit logs are automatically and continuously analysed, or logs are reviewed monthly to check for any unauthorised activity. The audit logs are also manually reviewed to search for any alerts or irregularities that for any reason have been missed by the automatic reviews. If such an irregularity is found the application for the automatic reviews will be updated to handle future irregularities of that type.

Telia also reviews its audit logs for suspicious or unusual activity in response to alerts generated based on irregularities and incidents within Telia CA and RA systems.

5.4.3 Retention period for audit log

Audit logs in accordance with section 5.4.1 are retained for at least seven (7) years from the date the entry is created or longer if required by law for audit and compliance purposes.

5.4.4 Protection of audit log

Logs are protected against improper alteration through the logical protection mechanism of the operating system and through the system itself not being physically or logically accessible other than by authorised personnel. Logging servers are protected from normal CA operators.

5.4.5 Audit log backup procedures

Audit logs are transferred online to at least two logging servers. Back-up copies of the system audit logs are made regularly according to defined schedules using offline storage media. Copies of the audit log and summaries of the inspection of audit logs are stored in physically secure locations in two physically separate places.

The logs are stored in such a way that they can, in the event of serious suspicion of irregularities, be produced and made legible for auditing during the stated storage time.

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

5.4.7 Notification to event-causing subject

Where an event is logged by the audit collection system, no notice is required to be given to the individual, organization, device, or application that caused the event.

5.4.8 Vulnerability assessments

The CA assesses the vulnerability of its critical systems regularly. The CA address any critical vulnerability not previously addressed by the Telia CA, within a period of 48 hours after its discovery. On the basis of the assessment results the configurations of firewalls and other systems are updated, and operation policies and practices are revised, if necessary.

Further details on vulnerability management timeframes in section 6.7.1.

5.5 Records archival

Telia archives relevant materials which affect the operation of the CA service. Procedures and prerequisites for this archiving are detailed in the following subsection.

5.5.1 Types of records archived

The following information is archived on an ongoing basis:

1. Transactions containing signed requests for certificate production and revocation of certificates from authorised operators

2. Certificate application documentation signed by applicant commissioners and by persons responsible for receiving and accepting applications

3. Signed receipt confirmations when issuing keys and codes

4. Issued certificates and related catalogue updates

5. History of previous CA keys, key identifiers, and cross certificates between different CA key generations

6. Revocation, suspension and re-instatement requests and related information received by the revocation service

7. CRL creation times and CRL catalogue updates

8. Results of reviewing Telia compliance with this CPS and other audits

9. Applicable terms and conditions and contracts (in all versions applied)

10. All CP and CPS versions published by the CA

In cases where the archived information constitutes a digitally signed volume of information, the necessary information required for verifying the signature during the stated archiving time is also archived.

5.5.2 Retention period for archive

Telia CA will retain all documentation relating to certificate requests and the verification thereof, and all certificates and revocation thereof, for at least seven (7) years from the date the entry is created, or longer if required by law, after any certificate based on that documentation ceases to be valid.

5.5.3 Protection of archive

The archives are stored also in locations other than the CA and RA sites. The archives are stored under such conditions that the archived material is protected from unauthorised viewing, modification, or deletion by physical protection and in some cases combined with cryptographic protection.

Archived material which is classified as confidential in accordance with section 9.3 is not accessible to external parties in its entirety other than as required by law and court orders.

Individual pieces of information relating to a specific key holder or transaction may be released after individual investigations.

The archive is stored under such conditions that it remains legible for auditing during the stated storage time.

However, the parties are made aware that technology for storing archived material may be changed and, in such an event, the CA is not obliged to retain functioning equipment for interpreting old, archived material if this is more than five years old. In such an event, the CA is however instead obliged to be prepared to set up the necessary equipment on payment of a charge corresponding to the costs of Telia.

If changes in procedures for access to archived material have been caused by Telia ceasing its operations, information on procedures for continued access to archived material shall be supplied by Telia through the notification procedures in accordance with section 5.8.

5.5.4 Archive backup procedures

Information to be archived is collected continuously from the places of origin and transferred to several online archives. Online archives are backed up regularly to offline archives.

5.5.5 Requirements for timestamping of records

All documents archived pursuant to this section will be marked with the date of their creation or execution.

The date and time information in the CA system and certain other system logs is synchronized with an external coordinated universal time source (UTC). The time used for the provision of revocation services is synchronized with UTC at least once every 24 hours.

5.5.6 Archive collection system (internal or external)

Telia is using internal archive systems and servers to collect archived information.

5.5.7 Procedures to obtain and verify archive information

Telia will verify the integrity of the backups at least once every 12 months to ensure usability of these backups. Material stored off-site will be periodically verified for data integrity.

5.6 Key changeover

Telia CA key pairs are retired from service at the end of their respective maximum lifetimes as defined in section 6.3.2. CA certificates may be renewed if 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.

A new set of CA key pairs is created at least three months before the point when the existing CA keys ceases to be used for issuing of new certificates.

5.6.1 Self-Signed CA

Changing of CA keys for a self-signed CA will be done, using the following procedure:

1. A new CA key pair is created

2. A new self-signed certificate is issued for the new public CA key

3. A cross certificate is issued where the new public CA key is signed using the old private CA key, and the certificates in accordance with b. to c. is published in the relevant directory

4. New Subscriber certificates are signed with the new private CA key

5. The old CA private key is used to issue CRLs until the expiration date of the last certificate issued using the old key pair has been reached

5.6.2 CA Hierarchies

Changing of CA key pairs for a subordinate CA will be done, using the following procedures:

1. A new subordinate CA key pair is created

2. A new subordinate CA certificate is issued for the new public CA key by the superior CA on the next level of the hierarchy

3. The certificate in accordance with b. is published in the relevant directory

4. New subordinate CA certificates or Subscriber certificates issued by the new subordinate CA are signed with the new private subordinate CA key

5. The old subordinate CA private key is used to issue CRLs until the expiration date of the last certificate issued using the old key pair has been reached

A superior CA ceases to issue new subordinate CA certificates no later than three months before the point in time where the remaining lifetime of the superior CA key pair equals the approved certificate Validity Period for the specific type of certificates issued by subordinate CAs in the superior CA’s hierarchy.

5.7 Compromise and disaster recovery

Telia has implemented a robust combination of physical, logical, and procedural controls to minimize the risk and potential impact of a key compromise or disaster. Telia has implemented disaster recovery procedures and key compromise response procedures described in this CPS. Telia’s compromise and disaster recovery procedures have been developed to minimize the potential impact of such an occurrence and restore Telia’s operations within a commercially reasonable period.

5.7.1 Incident and compromise handling procedures

Telia has implemented detailed change and incident management procedures to allow for controlled and accountable handling of incidents and recovery from system and application disasters.

Regarding disaster recovery at the site level Telia has implemented disaster recovery plans. Monitoring activities are considered based on the sensitivity/criticality of any information collected or analysed.

The business continuity plan include but is not necessarily limited to following:

1. The conditions for activating the plan
2. Emergency procedures
3. Fallback procedures
4. Resumption procedures
5. A maintenance schedule for the plan
6. Awareness and education requirements
7. The responsibilities of the individuals
8. Recovery time objective (RTO)
9. Regular testing of contingency plans
10. The CA’s plan to maintain or restore the CA’s business operations in a timely manner following interruption to or failure of critical business processes
11. A requirement to store critical cryptographic materials (i.e., secure cryptographic device and activation materials) at an alternate location
12. What constitutes an acceptable system outage and recovery time
13. How frequently backup copies of essential business information and software are taken
14. The distance of recovery facilities to the CA’s main site
15. Procedures for securing its facility to the extent possible during the period of time following a disaster and prior to restoring a secure environment either at the original or a remote site.

The plans shall be tested, outcome and results reviewed and procedures updated if neede at least on annual basis.

Detailed instructions are provided in the Telia CA operations with a Disaster Recovery Plan outlining the steps to be taken in the event of an incident and the incident reporting caused by such an incident.

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

In the event of the corruption of computing resources, software, and/or data, such an occurrence is reported to Telia Security staff and Telia’s incident handling procedures are initiated. Such procedures require appropriate escalation, incident investigation, and incident response. If necessary, Telia’s key compromise or disaster recovery procedures will be initiated.

5.7.3 Entity private key compromise procedures

Upon the suspected or known compromise of a Telia CA private key, Telia’s Key Compromise Response procedures are followed. Telia undertakes, on suspicion that Telia no longer has full and exclusive control of a CA’s private key, to take the following action:

1. Revoke the CA certificate associated to the compromised CA private key if the CA is a part of a CA hierarchy and make the updated ARL (ARL is CRL for CA certificates) publicly available

2. Cease all revocation checking services relating to certificates issued using the compromised key and all revocation checking services signed using the comprised key or keys certified using the compromised key. This means that all associated revocation lists are removed from their assigned locations

3. Inform all key holders and all parties with which Telia has a relationship that the CA’s private key has been compromised and how new CA certificates can be obtained

4. In the event that Telia has cross certified the compromised CA key with another operational CA key, revoke any such cross certificates Subscriber key holders will be informed that they should immediately cease using private keys which are associated with certificates issued using the compromised CA’s private key.

Key holders are furthermore informed how they should proceed in order to obtain replacement certificates and any new private keys, and the circumstances under which old private keys can be used in connection with other certificates which have not been issued using the compromised CA key.

Information will be made available to relying parties, who are clearly informed that the use of the affected certificates and the CA’s issuer certificate has been revoked.

The action of relying parties is outside Telia’s influence. Through Telia’s revocation information process, they will receive the necessary information to be able to take the correct action.

5.7.4 Business continuity capabilities after a disaster

Telia will provide business continuity procedures in a Disaster Recovery Plan that outline the steps to be taken in the event of corruption or loss of computing resources, software and/or data. Telia has implemented mission critical components of its CA infrastructure in redundant configurations. This applies both to hardware and software components. The main CA system components have been implemented in two data centers.

Telia maintains offsite backup of important CA information for CAs issued at the Telia’s premises. Such information includes but is not limited to: Backups of CA key pairs, application logs, certificate application data, audit data and database records for all certificates issued. In addition, CA private keys are backed up and maintained for disaster recovery purposes.

5.8 CA or RA termination

If it is necessary for a Telia CA to cease operation, Telia makes a commercially reasonable effort to notify Subscribers, Relying Parties, and other affected entities of such termination in advance of the CA termination.

Unless otherwise addressed in an applicable agreement between Telia and a Subscriber, Telia may:

1. Ensure that any disruption caused by the termination of an Issuing CA is minimized as much as possible

2. Provision of notice to parties affected by the termination, such as Subscribers Relying Parties, and Supervisory bodies and informing them of the status of the CA

3. Make public announcement in the CA repository at least three months in advance that operations will cease for the CA

4. Revoke all active Certificates before the end of the three months’ notice period

5. Destroy private keys, including backup copies, in a manner such that the private keys cannot be retrieved

6. Cease all revocation checking services relating to certificates issued using the CA keys of which use will cease. This means that all associated revocation lists are removed from their assigned locations and that no new revocation lists are issued to replace those that are removed

7. Terminate all rights for subcontractors to act in the name of the CA which will cease to operate

8. Ensure that all archive records of the issuing CA are retained

9. Prior terminating the CA services - if applicable depending on the agreed contracts, Telia may transfer provision of the CA services for its existing Subscribers to another CA successor entity

10. Notify relevant parties such as auditors, CA root programs and CCADB Telia has made arrangement to cover the costs to fulfil these minimum requirements in case the CA becomes bankrupt or for other reasons is unable to cover the costs by itself, as far as possible within the constraints of applicable legislation regarding bankruptcy.

6. TECHNICAL SECURITY CONTROLS

6.1 Key pair generation and installation

Telia CA uses cryptographic hardware security modules validated at least:

• FIPS 140-2 level 3³, or
• FIPS 140-3 level 3⁴, or
• Common Criteria Protection Profile or Security Target, EAL 4 (or higher)⁵

6.1.1 Key pair generation

The CA key pairs are generated in FIPS 140-2⁶ level 3 or higher validated cryptographic hardware modules designated to Telia CA.

Activation of the hardware requires the presence of two (2) authorized Trusted Role personnel. Telia produces auditable evidence during the key generation process to prove that the CPS was followed, and role separation was enforced during the key generation process.

Generation of key pairs for publicly trusted CA hierarchy requires that an external auditor witness the generation of any CA keys intended to be used for publicly trusted Root CA or publicly trusted Subordinate CA creation. CA key pair generation ceremony script must be approved and signed by Telia CA Security Board.

CA Key Pairs are generated by multiple trusted individuals acting in trusted roles and using dedicated cryptographic hardware device as part of scripted key generation ceremony in the environments described in section 5.1 and logged in accordance with section 5.4. The authorized trusted roles shall sign and document record of the key generation ceremony, as allowed by applicable policy.

RA keys used by Registration Officers are encrypted are securely used and kept secret privately by each Registration Officer.

Root CA keys are stored in offline state. They are activated only when needed. Two (2) duly authorized Trusted Role persons are required to activate offline key.

The Subscriber key pair may be generated by the Subscriber, or the Subscriber may use the registration tool provided by the CA to generate the key pair (PKCS#12 files). The Subscriber may also generate the key pair on a Smart Card or USB token. It is also possible use Smart Cards that have the key pair generated by the Card Manufacturer.

If the key pair is generated by the Subscriber in a Subscriber Organization, External RA is responsible for the secure generation of the key pair and the confidentiality of the private key.

If the key pair is provided by the CA, the generation will be carried out according to the secure procedures defined by the CA.

6.1.2 Private key delivery to Subscriber

The CA delivers the Subscriber’s private key on a Smart Card, on a USB token, or in a file to the Registration Officer in Subscriber Organization or to the Subject.

In case when Telia has initiated key generation and delivered hardware token to Subscriber the PIN code is protected cryptographically and delivered to the Subscriber separate from the hardware.

When the Subject generates his key pair, the private key will be recorded on the Subjects workstation, Smart Card or USB token, a separate delivery of the key is not needed.

Software certificates

If the key pair is generated using the self-service software provided by the CA, the private key is delivered to the Subscriber in a password protected PKCS#12 file. The Subscriber Registration Officer can download the PKCS#12 file directly from the application. Alternatively, Subscriber Registration Officer may generate a one-time password for the Subject to access the self-service software. Subject generates the key pair and downloads the PKCS#12 file.

6.1.3 Public key delivery to certificate issuer

Subscribers and RAs submit their public key to Telia for certification electronically through the use of a PKCS#10 CSR, certificate request syntax or other digitally signed package in a session secured by TLS.

Where CA, or RA key pairs are generated by Telia, this requirement is not applicable.

The public key is delivered digitally signed in a CSR file and using an encrypted connection.

6.1.4 CA public key delivery to relying parties

CA public key is made available in the form of signed X.509 certificate in Telia CA public repository (https://cps.trust.telia.com/). Certificate will be available in both Privacy Enhanced Mail (PEM) and Distinguished Encoding Rules (DER) format.

Telia CA’s publicly trusted Root CA and Subordinate CA public keys are made available to the relying parties as uploaded certificates in the Common CA Database (CCADB, https:/ccadb.force.com/).

Telia CA certificates are made available to Subscribers and Relying Parties through the public web repository. Subscriber (Private PKI) CA may be made available through the repository, if approved by the Subscriber.

Telia 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

Permitted key sizes and algorithms accepted by Telia CA are defined in the following sections.

No other key sizes or algorithms are permitted.

6.1.5.1 CA key pairs

Allowed key sizes and algorithms for CA key pairs are:

Algorithm	Allowed key sizes
rsaEncryption OID 1.2.840.113549.1.1.1	Mimimum 4096 bits Allowed 4096 and 8192 bits
ECDSA (id-ecPublicKey)	Mimimum NIST P-384 secp384r1 Allowed namedCurves secp384r1 OID 1.3.132.0.34 secp521r1 OID 1.3.132.0.35

6.1.5.2 Subscriber key pairs

Allowed key sizes and algorithms for Subscriber key pairs are:

Algorithm	Allowed key sizes
rsaEncryption OID 1.2.840.113549.1.1.1	Mimimum 3072 bits Allowed 3072, 4096 and 8192 bits
ECDSA (id-ecPublicKey)	Mimimum NIST P-256 secp256r1 Allowed namedCurves secp256r1 OID 1.2.840.10045.3.1.7 secp384r1 OID 1.3.132.0.34 secp521r1 OID 1.3.132.0.35

6.1.6 Public key parameters generation and quality checking

Telia uses a HSM device that conforms to FIPS 186-5 and provides random number generation and on-board generation of up to 8192 bit RSA Public Keys and a wide range of ECC curves.

CA keys are protected by a secure cryptographic hardware module rated at least FIPS 140-2, Level 3.

Telia verifies the quality of keys before accepting the certificate request in accordance with the requirements set forth in Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates section 6.1.6.

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

Issued certificates contain information which defines suitable areas of application for the certificate and its associated keys. The CA is not responsible for use other than the given key usage purposes. Area of application labelling takes place in accordance with X.509 and chapter 7.

Publicly Trusted S/MIME Certificates issued in accordance with this CP/CPS and adhering to the BR SHALL use keyUsage-extension in supported S/MIME profiles.

Profile	Key Usage per public key type
Multipurpose	RSA (rsaEncryption) For signing only, bit positions SHALL be set for digitalSignature. For key management only, bit positions SHALL be set for keyEncipherment. For dual use, bit positions SHALL be set for digitalSignature and keyEncipherment. Certificates issued MAY set nonRepudiation. EC (id-ecPublickey) For signing only, bit positions SHALL be set for digitalSignature. For key management only, bit positions SHALL be set for keyAgreement. For dual use, bit positions SHALL be set for digitalSignature and keyAgreement. Certificates issued MAY set nonRepudiation.
Strict	RSA (rsaEncryption) For signing only, bit positions SHALL be set for digitalSignature MAY be set for nonRepudiation. For key management only, bit positions SHALL be set for keyEncipherment. For dual use, bit positions SHALL be set for digitalSignature and keyEncipherment MAY be set for nonRepudiation. EC (id-ecPublickey) For signing only, bit positions SHALL be set for digitalSignature and MAY be set for nonRepudiation. For key management only, bit positions SHALL be set for keyAgreement. For dual use, bit positions SHALL be set for digitalSignature and keyAgreement and MAY be set for nonRepudiation.

6.1.7.1 Special considerations on Root CA private key use to sign certificates.

Telia CA uses Root CA Private keys only to sign certificates in following cases:

• Signing of self-signed Certificate to represent the Root CA itself
• Signing of subordinate CA certificates and Cross Certificates by the Root CA
• Signing of OCSP response verification certificates

6.2 Private key protection and cryptographic module engineering controls

Telia CA has implemented a combination of physical, logical, and procedural controls to ensure the security of Telia CA private keys. Logical and procedural controls are described here in section 6.2. Physical access controls are described in section 5.1.2. Subscribers are required by contract to take necessary precautions to prevent the loss, disclosure, modification, or unauthorised use of private keys.

The Subscriber is required to protect its private key from disclosure according to the requirements as defined by the issuing CA. The Subscriber is responsible for its private keys.

6.2.1 Cryptographic module standards and controls

All CA Digital Signature key generation, CA Digital Signature key storage and certificate signing operations will be performed in a hardware cryptographic module validated to at least FIPS 140-2 Level 3. The cryptographic module is physically protected within the protected environment defined in section 5.1.

All other CA cryptographic operations, such as certificates and keys used for administering the CA, will be performed with hardware based cryptographic module.

End entity private keys can be enclosed and protected in two different ways:

1. Hardware protected private keys which are created and stored in smart cards or equivalent chip-based hardware.
2. Software protected private keys generated by the CA or by the Subscriber

Software protected keys shall be stored in encrypted form with a security level which makes it unfeasible to crack the encryption protection through logical attacks. For this reason, key holders shall use methods and tools approved by the CA. For locally generated software-protected keys, it is the key holder (and the key holder’s organization) who takes sole responsibility for satisfactory security being achieved in the user’s local environment.

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

Telia has implemented technical and procedural mechanisms that require the participation of multiple Trusted Role individuals to perform CA cryptographic operations.

Telia uses “Secret Sharing” to split the recovery data needed to make use of a CA private key into separate parts called “Secret Shares”. A threshold number of Secret Shares (n) out of the total number of Secret Shares created and distributed for a particular hardware cryptographic module (m) is required to recover a CA private key stored on the cryptographic module.

6.2.3 Private key escrow

Telia CA does not escrow private keys.

6.2.4 Private key backup

Telia CA backup copies of CA and RA private keys for recovery purposes. Backup retrieval requires same access protection controls which apply to the original keys. At least two authorized Trusted Role persons are required to manage CA private key backups.

Telia backup subscriber and/or subject private keys, if separately agreed between Telia and the Subscriber. The backup keys are copied and stored in encrypted form and protected at a level no lower than of the keys in use.

No backups are made of the subject’s and/or subscriber’s private non-repudiation keys.

The Subscriber is responsible that no duplication of the private key is allowed, except for duly documented service availability purpose, and the duplicated key must abide at least the same security measures as the original. If the secure cryptographic hardware device is controlled directly by the signer, then the device must prevent exportation or duplication of the private key.

6.2.5 Private key archival

RA or CA private keys will be archived by Telia CA for disaster recovery purposes.

Telia CA does not archive Subscriber private keys.

6.2.6 Private key transfer into or from a cryptographic module

Telia CA generates CA key pairs on the hardware cryptographic modules in which the keys will be used. Where CA key pairs are transferred to another hardware cryptographic module for clustering reasons such key pairs are transported between modules in encrypted form using private networks dedicated for Telia CA.

In addition, Telia CA makes encrypted copies of CA key pairs for routine recovery and disaster recovery purposes.

6.2.7 Private key storage on cryptographic module

CA private digital signature key is kept in a secure cryptographic hardware module rated to at least FIPS 140-2 Level 3.

6.2.8 Method of activating private key

6.2.8.1 CA keys

The activation of the CA private key is done by person serving in authorized trusted role of the CA and authenticated with a two-factor authentication to activate the private key. The key remains active in the CA system for a single process until it is deactivated.

Essential information exchange between a RA and the CA is protected. All CA and RA operators are authenticated in CA or RA system in accordance with section 5.2.3 and transactions affecting the use of a CA’s private issuer keys are authenticated by the CA system based on a digital signature. Activation of the private key of the Telia RA requires the use of activation data as described in section 6.4.

6.2.8.2 Subscriber keys

Subscribers are solely responsible for protecting their Private Keys in a manner commensurate with the Certificate type. Subscribers should use a strong password or equivalent authentication method to prevent unauthorized access or use of the Subscriber’s Private Key. Subscribers should also take commercially reasonable measures for the physical protection of their workstation to prevent use of the workstation and its associated private key without the Subscriber’s authorization. When deactivated, private keys shall be kept in encrypted form only and secured. At a minimum, Subscribers are required to authenticate themselves to the cryptographic module before activating their Private Keys.

Telia recommends that Subscribers and Subscriber Registration Officers take as protective measure to store their private keys in encrypted form and protected by the use of a hardware token and/or strong passphrase. The use of two factor authentication mechanisms (e.g., token and passphrase or biometric and token) is encouraged.

For software keys Telia CA recommends that the Subscriber Organizations use passwords for private key activation as described in section 6.4 and take appropriate measures for the physical protection of the workstations or other devices used to store private keys.

6.2.9 Method of deactivating private key

6.2.9.1 CA keys

Telia’s CA private keys are deactivated via logout procedures on the applicable HSM device when not in use.

Telia never leaves its HSM devices in an active unlocked or unattended state.

6.2.9.2 Software keys

Deactivation of software keys should be performed according to software manufacturer’s instructions and recommendations. Software keys should be deactivated at all times when not attended.

6.2.9.3 Smart Cards and USB tokens

The private key on a Smart Card or USB token will be locked if the activation data related to it is inserted falsely too many times in succession. The lock-out threshold depends on the Smart Card or USB token type used and can be, for example, 3 or 5 failed attempts. A locked key can be returned into use with the help of a PUK code (PUK = PIN Unblocking Key) or equivalent technology (e.g. challenge/response).

Subscribers should deactivate their Private Keys via logout and removal procedures when not in use.

6.2.10. Method of destroying private key

For operational keys which are stored on the issuer system’s hard disk or other media in encrypted form, the following applies:

1. If the equipment is to be used further in the same protected environment, erasing is carried out in such a way that these keys cannot be recovered at least without physical access to the media. Old or broken CA key storage media may be temporarily stored in the protected CA environment.

2. If the media that has contained CA key material will permanently leave the protected CA environment, it will be destroyed. Physical destruction is used when destroying the media.

The Subscriber private confidentiality keys that are stored by the CA for backup purposes are securely destroyed at the end of service.

When the Subscriber’s certificate becomes expired and it is not renewed, related private key should be destroyed by the Subscriber.

6.2.11. Cryptographic module rating

All CA digital signature key generation, CA digital signature key storage and certificate signing operations are performed in a secure cryptographic hardware module rated to at least FIPS 140-2 Level 3.

See section 6.2.1.

6.3 Other aspects of key pair management

6.3.1 Public key archival

Telia CA retain public key archives as defined in section 5.5.2 of this CP/CPS.

6.3.2 Certificate operational periods and key pair usage periods

Telia CA operational periods for key pairs and certificates as depictedin below table.

Certificate type	Key pair usage period	Certificate term
Publicly Trusted Root CA	25 years	Maximum 25 years
Publicly Trusted Cross-Certified Subordinate CA	25 years	Maximum 25 years
Publicly Trusted Subordinate CA	25 years	Maximum 25 years
Subscriber certificates	Maximum 825 days	Maximum 825 days

Subscriber certificates issued in accordance with this CPS are issued for both new keys and for existing keys.

Certificate term is limited by the time of creation or issuance and notAfter is set to a date earlier or the same as expiration date of the key pair used for the Certificate.

Telia CA discourages reuse of key pairs over certificate’s lifetime.

The usage period of the public and private keys shall not exceed beyond the time the applied cryptographic algorithms and their pertinent parameters remain cryptographically secure or otherwise suitable.

For calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, represents an additional day. For purposes of calculating time periods in this document, increments are rounded down subject to the imposed maximum requirements.

6.4 Activation data

Telia CA activates the cryptographic module containing its CA Private Keys according to the specifications of the hardware manufacturer. For roots and public issuing CAs, this method has been evaluated as meeting at least the requirements of FIPS 140-2 Level 3. The cryptographic hardware is maintained under two-person control as explained in this CPS.

Activation data is transmitted via an appropriately protected channel and at a time and place that is distinct from the delivery of the associated cryptographic module.

Telia CA and RA operators are either using PIN protected private keys on smart cards or have private keys stored on personal computer hard disk. If the keys are stored on personal computer hard disk, private keys shall be protected by strong passwords meeting the criterion set forth in CA/Browser Forum Network and Certificate System Security Requirements.

Telia encourages Subscribers and Subscriber Registration Officers choose activation data that meet the requirements described above. Telia also recommends the use of two factor authentication mechanisms (e.g., token and pass phrase or biometric and token) for private key activation.

6.4.1 Activation data generation and installation

Activation data (secret shares) used to protect Telia CA, and private keys are generated in accordance with the requirements of section 6.2.2.

Telia CA and RA operators are either using smart cards with the private keys protected by PINs or have the private keys stored on a hard disk. If the keys are stored on a hard disk the CA and RA operators are required to select strong passwords to protect the private keys.

Telia strongly recommends that Subscribers and Subscribers RAs choose passwords that meet the same requirements. Telia also recommends the use of two factor authentication mechanisms (e.g., token and pass phrase or biometric and token) for private key activation.

Subscriber is responsible for activation data generation and installation. The Subscriber is recommended to use passwords or strong authentication methods to authenticate users to servers or other devices before the private key is activated. If passwords are used, the CA recommends that Subscriber uses passwords that consists of sufficiently many characters and cannot be easily guessed or concluded.

Software keys

When the Subject or subscriber Registration Officer generates a key pair, password or passphrase should be created as activation data, where applicable according to Subscriber Organization policy.

When Telia CA generates the key pair on behalf of the subscriber, the activation data shall be securely prepared and distributed separately.

Smart Cards and USB tokens

The Card Manufacturer, Subscriber Organization or RA system generates the activation data in pursuance of key pair generation.

6.4.2 Activation data protection

All activation data will be protected from unauthorised use by a combination of cryptographic and physical access control mechanisms as explained in this CPS. Activation data (Secret Shares) used to protect Telia CA private keys is stored in secure locations where at least two trusted individuals are required to access them. Telia CA and RA operators are required to store their Administrator private keys on smart cards or in encrypted form using password protection.

Telia CA personnel (internal or external), Subscribers and, Subscriber Registration Officers shall protect the activation data for their private keys against loss, disclosure,modification, or unauthorised use. Any activation data should be memorized and not to be written down in any form or disclosed to other individuals.

Subscribers shall instruct their Subjects protect activation data in similar manner.

Secure delivery may be, but not limited to, achieved by:

• Concealed under a protective surface layer or enclosed in a sealed envelope
• Or other similar secure method

When Telia CA generates the key pair, the activation data and the private key are delivered separately to the Subscriber. See also 6.2.8 regarding type (iv) certificates.

When subscriber Registration Officer generates the key pairs, the organization is responsible for the secure delivery of the activation data to the Subject.

6.4.3 Other aspects of activation data

Not applicable.

6.5 Computer security controls

6.5.1 Specific computer security technical requirements

The entire CA system is built in such a way that individual roles as per section 5.2 can be separated. The access control systems used is built in such a way that every operator is identified at an individual level and authenticated in accordance with the section 5.2.3.

The above shall apply regardless of whether an operator acts directly within the CAs central premises or whether the operator is in an external RA function.

6.5.2 Computer security rating

No stipulation.

6.6 Life cycle security controls

6.6.1 System development controls

Two-phase testing is used in the development of the CA and RA production systems. The changes that have emerged because of development work will be first tested in a separate development system. After a successful testing the changes are updated to the staging system. The acceptance test is performed in the test system before the changes are taken into production.

All the changes in the system are properly documented.

6.6.2 Security management controls

Telia’s Group Security Policy apply to the Telia CA. Furthermore, the CA follows the security instructions and guidelines, applicable CP/ CPS governing the CA operations. The auditing of the operation has been described in chapter 8.

Evaluation of business risks and establishment of reaction and recovery models for potential risks belong to the management of the Business Continuity Plan drawn up by the CA. The reporting of abnormal events and of detected or suspected weaknesses in security is carried out according to the procedures defined by the CA.

The CA ensures by contractual arrangements that the level of security is preserved also when the outsourced functions are concerned, and that the defined policies and practices are followed also when subcontractors are involved.

Operational documentation has been drawn up which documents in detail how roles and authorisation are applied and maintained.

6.6.3 Life cycle security controls

Telia has prevented developers to access production systems. Versions and releases are separated from each other using software management tools designed to this purpose. Each update to production is approved and documented.

6.7 Network security controls

Telia CA services are secured by two-factor authentication through VPN to protect data and systems from unauthorised personnel. Suspicious login attempts or activities will be monitored and alerted by the intrusion detection system. Industry best practices are followed for securing the CA networks, for example by conforming to the CA/B Forum Network Security Guidelines⁷.

Firewalls have been implemented to restrict access to the Telia CA equipment. Only specified traffic allowed through network boundary controls such as protocols and ports required by Telia CA’s operations.

Essential information exchange between the RA and Telia CA is encrypted and transactions affecting the use of the CA’s private issuer keys are individually signed. All communication ports in the CA system which are not needed are deactivated and associated software routines which are not used are blocked.

Telia CA services are secured by two-factor authentication through VPN to protect data and systems from unauthorised personnel. Suspicious login attempts or activities will be monitored and alerted by the intrusion detection system.

6.7.1 Vulnerability management timeframes

Identified vulnerabilities are reviewed, responded to, and remediated by Telia CA as disclosed in this section.

Each timeframe is defined based on a Risk Assessment performed by Telia CA. Vulnerability classification is based on Common Vulnerability Scoring System (CVSS) v3.

Criticality	Response Timeframe	Remediation Timeframe
Critical	48 hours	48 hours from the availability of the remediation
High	7 days	Next scheduled monthly patching from the availability of the remediation
Medium, Low	30 days	Next scheduled monthly patching from the availability of the remediation
No CVE rating	30 days	Next scheduled monthly patching from the availability of the remediation

Within the Response Timeframe the vulnerability is assessed and plan to remediate the issue compiled. If immediate remediation is not available, Telia CA will identify possible mitigations to manage the impact until remediation is available.

6.8 Timestamping

The system time on Telia CA computers is updated using the Network Time Protocol (NTP) to synchronize system clocks. The used Telia NTP servers are using time where quality is on level Stratum-3.

7. CERTIFICATE, CRL, AND OCSP PROFILE

7.1 Certificate profile

The contents definition of a certificate, in other words the certificate profile, defines the fields in a certificate. The certificate profile of the certificates follows the version 3 profile defined in the ITU X.509 standard. The profile of the certificates also follows the document RFC 5280 “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”.

7.1.1 Version number(s)

All issued certificates are X.509 Version 3 certificates, in accordance with the PKIX Certificate and CRL Profile.

7.1.2 Certificate content and extensions

This section specifies the additional requirements for Certificate content and extensions for Certificates. Certificate extensions will be supported in accordance with RFC 5280 and RFC 6818.

Fields common to all certificates issued under this CP/CPS:

Field	Field description and contents
Version	This field states which of the certificate versions defined in the X.509 standard the certificate conforms to. The issued certificates conform to the version 3
Serial number	The CA generates an individual random serial number for every certificate. The number that has been given in this field is unique for every certificate created by the CA system. The software manages the uniqueness of the serial number automatically guaranteeing non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG.
Signature algorithm	See section 7.1.3
Issuer	This field states the name of the Issuer of the certificate. The Issuer name in the certificates of each CA has been described in section 1.3.1.
Validity	The validity of the certificate is that period during which the CA guarantees that it maintains status information of the certificate, in other words about the possible revocation of the certificate. This field states the date and time when the certificate comes into force, and the date and time after which the certificate is no more valid. The certificate can be trusted during its validity period if the certificate has not been published on the CRL.
Subject	This field identifies the Subject under whose possession the private key is, that corresponds to the public key contained in the certificate. The field includes the unambiguous name of the Subject. The contents of the field have been described in section 3.1 and 7.1.4
Subject public key info	See section 7.1.3

7.1.2.1 Root CA certificates

Content for self-signed root CA certificates issued by Telia CA.

Field	Critical	Field contents
basicConstraints OID 2.5.29.19	YES	cA=true
keyUsage OID 2.5.29.15	YES	Bit positions for keyCertSign and cRLSign set
subjectKeyIdentifier OID 2.5.29.14	NO	SHA-1 identifier of the self-signed root CA public key
authorityKeyIdentifier OID 2.5.29.35	NO	SHA-1 identifier of the self-signed root CA public key

7.1.2.2 Subordinate CA certificates

Content for subordinate CA certificates issued by Telia CA’s self-signed root CA.

Field	Critical	Field contents
basicConstraints OID 2.5.29.19	YES	cA=true, pathLenConstraint=0 set for issuing CAs
keyUsage OID 2.5.29.15	YES	Bit positions for keyCertSign and cRLSign set
subjectKeyIdentifier OID 2.5.29.14	NO	SHA-1 identifier of the subordinate CA public key
authorityKeyIdentifier OID 2.5.29.35	NO	SHA-1 identifier of the issuing self-signed root CA public key
certificatePolicies OID 2.5.29.32	NO	For cross-signed subordinate CA anyPolicy (2.5.29.32.0). For issuing CAs as defined in section 1.2
cRLDistributionpoints OID 2.5.29.31	NO	HTTP URL of the CA’s CRL service
authorityInformationAccess OID 1.3.6.1.5.5.7.1.1	NO	HTTP URL of the Issuing CA Certificate (accessMethod = 1.3.6.1.5.5.7.48.2) May contain the HTTP URL of the Issuing CA OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1)
nameConstraints OID 2.5.29.30	YES	Set for Technically constrained subordinates CAs as described in section 7.1.5
extKeyUsage OID 2.5.29.37	NO	id-kp-emailProtection is set always, id-kp-clientAuth may be set

7.1.2.3 Subscriber certificates

Content for Subscriber certificates issued by Telia CA’s subordinate CAs.

Field	Critical	Field contents
basicConstraints OID 2.5.29.19	NO	cA=false, pathLenConstraint shall not be present
keyUsage OID 2.5.29.15	YES	The key usage purposes of the public key contained in the certificate are given in this extension. The key usage purposes of the public keys contained in the certificates are listed in section 6.1.7.
subjectKeyIdentifier OID 2.5.29.14	NO	SHA-1 identifier of the subordinate CA public key
authorityKeyIdentifier OID 2.5.29.35	NO	SHA-1 identifier of the issuing self-signed root CA public key
certificatePolicies OID 2.5.29.32	NO	Policy identifiers as described in section 7.1.6.1
cRLDistributionpoints OID 2.5.29.31	NO	HTTP URL of the issuing CA’s CRL service
authorityInformationAccess OID 1.3.6.1.5.5.7.1.1	NO	HTTP URL of the Issuing CA Certificate (accessMethod = 1.3.6.1.5.5.7.48.2) May contain the HTTP URL of the Issuing CA OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1)
nameConstraints OID 2.5.29.30	YES	Set for Technically constrained subordinates CAs as described in section 7.1.5
extKeyUsage OID 2.5.29.37	NO	id-kp-emailProtection is set always, id-kp-clientAuth may be set
subjectAlternativeName OID 2.5.29.17	NO	GeneralName of type Rfc822Name as described in section 3.1.1

No other extensions may be used in Subscriber certificates, if agreed with Telia or added to CSR and CA is aware of a reason for including the data in the certificate. Telia CA SHALL ensure before accepting any value to be set in Subscriber certificate, that the Subscriber certificate contents comply with Baseline Requirements section 7.1.2 and adequate documentation supporting and explaining the authorization to use such extensions.

7.1.2.4 All certificates

All fields and extensions SHALL be set in accordance with RFC 5280. Telia CA shall not issue a Certificate that contains a keyUsage flag, extKeyUsage value, Certificate extension, or other data not specified in Section 7.1.2.1, Section 7.1.2.2, or Section 7.1.2.3.

Telia CA shall not issue a Certificate with:

• Extensions that do not apply in the context of the public Internet
• Field or extension values which have not been validated according to the processes and procedures described in this CP/CPS.

7.1.3 Algorithm object identifiers

Telia CA uses following algorithms and algorithm identifiers in issued certificates in accordance with the Baseline Requirements.

7.1.3.1 SubjectPublicKeyInfo

Algorithm	Object Identifier OID
rsaEncryption	1.2.840.113549.1.1.1
ECDSA namedCurve secp256r1	1.2.840.10045.3.1.7
ECDSA namedCurve secp384r1	1.3.132.0.34
ECDSA namedCurve secp521r1	1.3.132.0.35

No other encodings are permitted.

7.1.3.2 SignatureAlgorithmIdentifier

Telia CA uses following signature algorithms and algorithm identifiers when signing objects with CA Private Key in accordance with the Baseline Requirements.

Algorithm	AlgorithmIdentifier
RSASSA‐PKCS1‐v1_5 with SHA‐256	300d06092a864886f70d01010b0500
RSASSA‐PKCS1‐v1_5 with SHA‐384	300d06092a864886f70d01010c0500
RSASSA‐PKCS1‐v1_5 with SHA‐512	300d06092a864886f70d01010d0500
secp256r1 ECDSA with SHA-256	300a06082a8648ce3d040302
secp384r1 ECDSA with SHA-384	300a06082a8648ce3d040303
secp521r1 ECDSA with SHA-512	300a06082a8648ce3d040304

No other encodings are permitted.

7.1.4 Name forms

Attribute values shall be encoded according to RFC 5280.

Name forms are stipulated in section 3.1.1.

7.1.4.1 Name encoding

For every valid Certification Path (as defined by RFC 5280, Section 6):

• For each Certificate in the Certification Path, the encoded content of the Issuer Distinguished Name field of a Certificate shall be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA Certificate.
• For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate shall be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to RFC 5280, Section 7.1, and including expired and revoked Certificates.

7.1.4.2 Subject information - subscriber certificates

Telia CA represents that it followed the procedure set forth in its CP and/or CPS to verify that, as of the Certificate’s issuance date, all of the Subject Information was accurate.

Mailbox Address shall not be included in a Mailbox Field except as verified in accordance with Section 3.2.2

Subject attributes shall not contain only metadata such as ‘.’, ‘-’, and ’ ’ (i.e., space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.

7.1.4.3 Subject information - root certificates and subordinate CA certificates

Telia CA represents that it followed the procedure set forth in its CP and/or CPS to verify that, as of the Certificate’s issuance date, all of the Subject Information was accurate.

Root CA and Subordinate CA subject information is set as presented in section 3.1.1.

7.1.4.3.1 Subject distinguished name fields

1. Certificate Field: subject:commonName (OID 2.5.4.3) shall be present and contains an identifier for the Certificate such that the Certificate’s Name is unique across all Certificates issued by the Issuing CA.

2. Certificate Field: subject:organizationName (OID 2.5.4.10) shall be present and contains either the Subject CA’s name or DBA as verified under Section 3.2.3.2.2. Field may include information in that differs slightly from the verified name, such as common variations or abbreviations. If provided that Telia CA documents the difference and any abbreviations used are locally accepted abbreviations.

3. Certificate Field: subject:countryName (OID: 2.5.4.6) shall be present contains the two‐letter ISO 3166‐1 country code for the country in which the CA’s place of business is located.

Other attributes shall not be present within the subject field.

7.1.5 Name constraints

Telia CA issued Subordinate CA Certificate considered Technically Constrained shall include the nameConstraints X.509v3 extension with constraints on rfc822Name as follows:

• For each rfc822Name in permittedSubtrees, each rfc822Name shall contain either a FQDN or a U+002E FULL STOP (“.”) character followed by a FQDN. The rfc822Name shall not contain an email address. Telia confirms that the Applicant has registered the FQDN contained in the rfc822Name or has been authorized by the domain registrant to act on the registrant’s behalf in line with the verification practices of Section 3.2.2.3.

7.1.6 Certificate policy object identifier

The certificate policy object identifier will be present in issued certificates and will contain the OID of the policy according to which the certificate has been issued. The identifiers covered by this CPS have been given in section 1.2.

7.1.6.1 Policy identifiers for subscriber certificates

Telia CA supports and sets following reserved policy identifiers (as defined by CA/Browser forum) and custom policy identifiers for subscriber certificates.

Reserved identifiers

Certificate type	Generation	Reserved identifier
Mailbox validated	Multipurpose	2.23.140.1.5.1.2
Mailbox validated	Strict	2.23.140.1.5.1.3
Organization validated	Multipurpose	2.23.140.1.5.2.2
Organization validated	Strict	2.23.140.1.5.2.3
Sponsor validated	Multipurpose	2.23.140.1.5.3.2
Sponsor validated	Strict	2.23.140.1.5.3.3

Custom identifiers

Issuing CA	Custom identifier	Description
Telia RSA Email CA v6	1.3.6.1.4.1.271.2.3.1.1.14	Policy Identifier for subscriber certificates issued for Telia subscribers
Ericsson NL Indivdual CA v5	1.3.6.1.4.1.271.2.3.1.1.18	Policy Identifier for subscriber certificates issued for Telefonaktiebolaget LM Ericsson subjects

7.1.7 Usage of Policy Constraints extension

Not applicable.

7.1.8 Policy qualifiers syntax and semantics

The policy qualifier CPSuri is used in the Subscriber certificates. The value of the CPSuri points to Telia CA Services repository website where this CPS is published.

7.1.9 Processing semantics for the critical Certificate Policies extension

Not applicable.

7.2 CRL profile

Telia CAs issues CRLs compliant with RFC 5280.

7.2.1 Version number(s)

All issued CRL’s are X.509 version 2 CRL’s in accordance with the RFC 5280 “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”.

7.2.2 CRL and CRL entry extensions

CRL extensions will be supported in accordance with RFC 5280 “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”.

Telia CA CRLs adhere to following:

• If present, the reasonCode (OID 2.5.29.21) extension will not be marked critical.

• CRLs published under this CP/CPS reasonCode shall not contain CRLreason of certificateHold (#6) for any certificate entry.

• For a Root CA or Subordinate CA Certificate, including Cross Certificates, this CRL entry extension will be present.

• If a CRL entry is for a Certificate not technically capable of causing issuance, reasonCode CRL entry extension shall be present for other reasonCodes than unspecified (0). If the reason for revocation is unspecified, the reasonCode entry extension is omitted.

• When reasonCode CRL entry extension is present, the CRLReason indicates the most appropriate reason for revocation of the Certificate, as defined in this CP/CPS.

The CRL extensions contain the following elements:

Extension	Extension description and contents
Authority key identifier OID 2.5.29.35	The identifier of the issuing CA public key is given in this extension. The identifier can be used to identify the public key that corresponds to the private key used for the signing of the certificate. SHA-1 hash algorithm is used to calculate the identifier.
CRL Number OID 2.5.29.20	Increasing sequence number for a given CRL scope and CRL issuer

The following CRL entry extensions may be included in a CRL:

CRL Entry Extension	Extension description and contents
Reason Code of the CRL Entry OID 2.5.29.21	For CRL Entries of Root CA, Subordinate CA and Cross-Certifier Subordinate CA reasonCode is always present. For a Certificate not technically capable of causing issuance reasonCode is present unless reasonCode is unspecified (0)

7.3 OCSP profile

Telia CA supports OCSP responders conform to the RFC 6960.

If an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross Certificates, and that Certificate has been revoked, then the revocationReason field within the RevokedInfo of the CertStatus shall be present.

The CRLReason indicated contains a value permitted for CRLs in this CP/CPS.

7.3.1 Version number(s)

Telia CA OCSP responders conform to RFC6960.

7.3.2 OCSP extensions

The singleExtensions (if present) of an OCSP response does not contain reasonCode (OID 2.5.29.21) CRL entry extension.

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

The purpose of a compliance audit is to verify that the Telia root CAs and SubCAs operate in accordance with this CP/CPS. Telia CA selects an independent Qualified Auditor for auditing its compliance assessments.

8.1 Frequency or circumstances of assessment

Telia CA maintains its compliance with the ETSI standards via a Qualified Auditor on an annual and contiguous basis.

8.2 Identity/qualifications of assessor

The CA’s audit will be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills:

1. Independence from the subject of the audit

2. The ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme (see Section 8.4)

3. Employs individuals who have proficiency in examining PKI technology, information security tools and techniques, information technology and security auditing, and the third‐party attestation function

4. For audits conducted in accordance with any one of the ETSI standards accredited in accordance with ISO 17065 applying the requirements specified in ETSI EN 319 403

5. (For audits conducted in accordance with the WebTrust standardvlicensed by WebTrust), not applicable to Telia CA

6. Bound by law, government regulation, or professional code of ethics

7. Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage

8.3 Assessor’s relationship to assessed entity

The Qualified Auditor should not have any financial, legal, or organizational relationship with the audited party. A person cannot be a Qualified Auditor if he/she:

1. is owner to or joint owner to Telia or another company within the same group

2. is a member of the Telia management or the management of any subsidiary, or assists with Telia’s bookkeeping or management of means, or Telia’s control of them, or managing the issues regarding information security

3. is employed by or in other aspects in subordinate or dependent relation to Telia or any other company referred to in a. and b. above

4. is married to or cohabiter with or is sibling or close relative to a person that is referred to in a. and b. above

5. is in debt to Telia or any other company referred to in a. to c. above

8.4 Topics covered by assessment

Telia CA undergo an audit in accordance with following schemes:

1. ETSI TS 119 411-6 v1.1.1 or newer, which includes normative references to ETSI EN 319 401, ETSI EN 319 411-1 and ETSI EN 319 411-2 (the latest version of the referenced ETSI documents applied)

The audit is conducted by a Qualified Auditor, as specified in Section 8.2.

Telia CA does not use Delegated Third Parties that are not Enterprise RAs.

8.5 Actions taken as a result of deficiency

Depending on the severity of the deficiency, the following actions may be taken:

1. The Qualified Auditor may note the deficiency as part of the report

2. The Qualified Auditor may meet with Telia and determine if the deficiency can be remedied, and an action plan should be developed and steps taken to remedy the deficiency. Such steps could be to change applied procedures and/or updating the CPS

3. The Qualified Auditor may report the deficiency and if the Telia CA Service deems the deficiency to have risk to the operation of the Telia, the Telia CA Service operator may revoke the CA’s certificate Should the CPS be updated in such a way that the new CPS is deemed to involve an amended degree of security; a new CPS with a new identity shall be drawn up (see section 1.2).

8.6 Communication of results

The Audit Report states explicitly that it covers the relevant systems and processes used in the issuance of all Certificates that assert one or more of the policy identifiers listed in Section 7.1.6.

Telia CA ensures its Audit Report publicly available no later than three months after the end of the audit period. In the event of a delay greater than three months, Telia CA provides an explanatory letter signed by the Qualified Auditor.

An authoritative English language version of the publicly available audit information will be provided by the Qualified Auditor and Telia CA ensures it is publicly available in PDF.

8.7 Self-audits

During the period in which Telia CA issues Certificates, the CA monitors adherence to its CP/CPS and CA/B Forum Requirements and strictly control its service quality by performing self-audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken.

Telia CA employs linting process to verify the technical accuracy of Certificates within the selected sample set independently of previous linting performed on the same Certificates.

8.8 Review of delegated parties

Telia CA has no delegated Trusted Third-Parties applicable to this CP/CPS that are applicable of self-audits.

9. OTHER BUSINESS AND LEGAL MATTERS

9.1 Fees

Fees are defined in server certificate order site or in applicable Subscriber Agreement.

9.1.1 Certificate issuance or renewal fees

See section 9.1.

9.1.2 Certificate access fees

See section 9.1.

9.1.3 Revocation or status information access fees

See section 9.1.

9.1.4 Fees for other services

See section 9.1.

9.1.5 Refund policy

Subscriber pays Telia for a service and its use pursuant to a pricelist or agreement according to invoicing periods defined by Telia. If Subscriber revokes Certificate(s) or requests a revocation to be done by Telia within a calendar month, then the purchase fee will be cancelled, and Subscriber is not required to pay the Certificate invoice.

9.2 Financial responsibility

9.2.1 Insurance coverage

Telia CA maintain Professional Liability/Errors & Omissions insurance with a policy limit of at least 1 million Euros in coverage.

9.2.2 Other assets

No stipulation.

9.2.3 Insurance or warranty coverage for end-entities

Warranty coverage is explained in section “9.6 Representations and warranties”.

9.3 Confidentiality of business information

All Subscriber’s information that is collected, generated, transmitted or maintained by the issuer is classified in accordance with the Telia’s Group Security Policy⁸.

Information published in the Repository such as public certificates or certificate revocation information are not considered as confidential.

9.3.1 Scope of confidential information

The following information are kept confidential and private:

• CAs, RAs application records whether approved or rejected

• CAs business continuity plan

• Security practices and related information

• Private keys

• Any other information identified as confidential by the PMT or the CAs that needs to be considered confidential

Telia will disclose confidential information where this is required by law or by a decision of a court or public authority. Private keys linked to issued certificates cannot be disclosed when these are not stored by Telia.

9.3.2 Information not within the scope of confidential information

The following information is not deemed to be confidential:

1. Information in issued certificates including public keys (but not private keys)

2. Revocation lists and OCSP responses

3. General Subscriber Agreement and CPSes

Exceptions may apply to key holder information if this is stated in a specific agreement with the key holder’s organization.

9.3.3 Responsibility to protect confidential information

All confidential information will be physically and/or logically protected by CA from unauthorised viewing, modification, or deletion.

Storage media used by the CA system is protected from environmental threats such as temperature, humidity and magnetism and that also applies to backup and archive media.

Confidentiality keys will in some cases be backed up by Telia, and in those cases the keys will be protected in accordance with Section 6, and will not be disclosed without prior consent of the Subscriber or a duly authorised representative of the issuing CA.

9.4 Privacy of personal information

Telia does not collect any sensitive or confidential data from Subscriber.

9.4.1 Privacy plan

The collected personal information will not be used for any other purpose and Telia’s privacy policy ⁹ governs the CA operations. Telia’s Privacy Notice applies to all processing of personal data ¹⁰.

9.4.2 Information treated as private

Telia CA or RA shall treat all personal information about an Individual that is not publicly available in the contents of a Certificate as private information, for example copies of identification documents to validate the identity of a Subscriber.

This includes information that links a Pseudonym to the real identity of the Subject Individual.

9.4.3 Information not deemed private

No stipulation.

9.4.4 Responsibility to protect private information

Telia CA or RA shall protect private information using appropriate safeguards and a reasonable degree of care and requires the same from any service providers who handle private information on behalf of the CA or RA.

9.4.5 Notice and consent to use private information

Telia CA or RA shall provide appropriate notices to, and receive the necessary consent, from Subject Individuals before using private information for any purpose other than providing services related to the issuance and management of Certificates and requires the same from any service providers who handle private information on behalf of the CA or RA.

9.4.6 Disclosure pursuant to judicial or administrative process

No stipulation.

9.4.7 Other information disclosure circumstances

No stipulation.

9.5 Intellectual property rights

The private signing key is the sole property of the legitimate holder of the corresponding public key identified in a certificate.

No part of this CPS (other than in accordance with the exceptions detailed below) may be reproduced, published in a database system or transmitted in any form (electronic, mechanical, photocopied, recorded or similar) without written permission from Telia Company AB.

However, permission generally applies for reproducing and disseminating this CPS in its entirety provided that this is at no charge and that no information in the document is added to, removed or changed.

Applications to reproduce and disseminate parts of this document in any other way may be made to Telia in accordance with section 1.5.2.

9.6 Representations and warranties

9.6.1 CA representations and warranties

Telia CA (Root CA and Subordinate CA) makes no representation concerning the quality of the Services and does not promise that the Services will:

1. Meet the Subscriber’s requirements or be suitable for a particular purpose, including that the use of the Services will fulfil or meet any statutory role or responsibility of the Subscriber or

2. The provided Services will be error free.

By issuing a Certificate, Telia CA makes the warranties listed herein to the following Certificate Beneficiaries:

1. The Subscriber that is a party to the Subscriber Agreement or Terms of Use for the Certificate

2. All Application Software Suppliers with whom the Root CA has entered into a contract for inclusion of its Root CA Certificate in software distributed by such Application Software Supplier and

3. All Relying Parties who reasonably rely on a Valid Certificate. Telia CA represents and warrants to the Certificate Beneficiaries that, during the period when the Certificate is valid, Telia CA has complied with these Requirements and its CP and/or CPS in issuing and managing the Certificate.

The Certificate Warranties specifically include, but are not limited to, following:

1. Right to Use Mailbox Address: at the time of issuance

   • implemented a procedure for verifying that the Applicant either had the right to use, or had control of, the Mailbox Addresses listed in the Certificate’s subject field and subjectAltName extension (or was delegated such right or control by someone who had such right to use or control)
   • followed the procedure when issuing the Certificate and
   • accurately described the procedure in the CA’s CP and/or CPS

2. Authorization for Certificate: at the time of issuance

   • implemented a procedure for verifying that the Subject authorized the issuance of the Certificate and that the Applicant Representative is authorized to request the Certificate on behalf of the Subject;
   • followed the procedure when issuing the Certificate and
   • accurately described the procedure in the CA’s CP and/or CPS

3. Accuracy of Information: at the time of issuance

   • implemented a procedure for verifying the accuracy of all of the information contained in the Certificate (with the exception of the subject:serialNumber attribute);
   • followed the procedure when issuing the Certificate and
   • accurately described the procedure in the CA’s CP and/or CPS

4. Identity of Applicant, if the Certificate contains Subject Identity Information:

   • implemented a procedure to verify the identity of the Applicant in accordance with Section 3.2 and Section 7.1.4.2.2
   • followed the procedure when issuing the Certificate and
   • accurately described the procedure in the CA’s CP and/or CPS

5. Subscriber Agreement: If the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements, or, if the CA and Subscriber are the same entity or are Affiliated, the Applicant Representative acknowledged the Terms of Use

6. Status: Telia CA maintains a 24 x 7 publicly-accessible Repository with current information regarding the status (Valid or Revoked) of all unexpired Certificates and

7. Revocation: Telia CA will revoke the Certificate for any of the reasons specified in these Requirements.

The Root CA shall be responsible for the performance and warranties, compliance with these Requirements, and for all liabilities and indemnification obligations of the Subordinate CA under these Requirements, as if the Root CA were the Subordinate CA issuing the Certificates.

9.6.2 RA representations and warranties

The CA bears overall responsibility for the issued certificates. Registration responsibilities of the CA’s overall responsibility can, however, be transferred through an agreement between the CA and a Third Party, when the last-mentioned becomes a Registration Authority. A Subscriber can, through an agreement, take responsibility for a separately defined part of the CA’s responsibilities related to registration.

Telia will require that all Registration Officers comply with all the relevant provisions of this CPS. Telia will make available registration policies and Subscriber responsibility descriptions to Subscribers acting as RA and will require them to comply with the registration policies and Subscriber responsibility descriptions through a certification service agreement. The registration policies and Subscriber responsibility descriptions contain all relevant information pertaining the rights and obligations of the Registration Officers, Subscribers and Relying Parties.

The Registration Officer is responsible for the identification and authentication of Subscribers following section 3.1 and section 4.1. The Registration Officer is also responsible for revoking certificates in accordance with the CPS.

Registration Officers are individually accountable for actions performed on behalf of a CA. Individually accountability means that there must be evidence that attributes an action to the person performing the action (audit logs). Records of all actions carried out in performance of RA duties shall identify the individual who performed the duty. When an RA submits Subscriber information to a CA, it will certify to that CA that it has authenticated the identity of that Subscriber and that the Subscriber is authorised to submit a certificate request in accordance with the CPS.

Submission of the certificate request to the CA will be performed in a secure manner as described in the applicable CPS.

All Registration Officers are authenticated when performing any actions in the RA applications. The audit logs are the main tool to control any misuse of the RA personnel’s authorities. For the processes authenticating the RA personnel see section 5 of this CPS.

9.6.3 Subscriber representations and warranties

Telia will require that Subscribers comply with all the relevant provisions of this CPS. Subscribers are required to protect their private keys, associated pass phrase(s) and tokens, as applicable, and to take all reasonable measures to prevent their loss, disclosure, modification, or unauthorised use.

Prior to the issuance of a Certificate Telia CA shall obtain either

1. The Applicant’s agreement to the Subscriber Agreement with the CA, or

2. The Applicant’s acknowledgement of the Terms of Use.

Any Subscriber information shall be complete, validated, and accurate with full disclosure of all required information in connection with a certificate or a query to a CA.

The Subscriber shall only use the keys and certificates for the purposes identified in applicable CPS and in any applicable agreement(s).

When a Subscriber suspects a private key compromise, the Subscriber shall notify Telia CA according to the contact information of section 1.5.1.

Telia is not a trustee, agent, fiduciary, or other representative of the Subscriber and the relationship between Telia, and the Subscriber is not that of an agent and a principal. Telia makes no representation to the contrary, either implicitly, explicitly, by appearance or otherwise.

The Subscriber does not have any authority to bind Telia by contract, agreement or otherwise, to any obligation.

The Subscriber Agreement or Terms of Use contain provisions imposing on the Applicant itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service relationship) the following obligations and warranties:

1. Accuracy of Information: An obligation and warranty to provide accurate and complete information at all times to the CA, both in the Certificate Request and as otherwise requested by the CA in connection with the issuance of the Certificate(s) to be supplied by the CA

2. Protection of Private Key: An obligation and warranty by the Applicant to take all reasonable measures to assure control of, keep confidential, and properly protect at all times the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device such as a password or token)

3. Acceptance of Certificate: An obligation and warranty that the Subscriber will review and verify the Certificate contents for accuracy

4. Use of Certificate: An obligation and warranty to use the Certificate only on MailBox Addresses listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use

5. Reporting and Revocation: An obligation and warranty to:

   • promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate, and
   • promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate

6. Termination of Use of Certificate: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise.

7. Responsiveness: An obligation to respond to the CA’s instructions concerning Key Compromise or Certificate misuse within a specified time period.

8. Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA is entitled to revoke the Certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or Terms of Use, or if revocation is required by the CA’s CP and/or CPS, or by these Requirements.

9.6.4 Relying party representations and warranties

Telia will require that Relying Parties comply with all the relevant provisions of this CPS.

Prior to accepting a Subscriber’s certificate, a relying party isresponsible to:

1. Verify that the certificate is appropriate for the intended use

2. Check the validity of the certificate, i.e. verify the validity dates and the validity of the certificate and issuance signatures

3. Check the status of the certificate against the appropriate and current CRL or OCSP Responder in accordance with the requirements stated in this CPS. As part of this verification process the digital signature of the CRL or OCSP Responder should also be validated. If certificate status can’t be received due to system failure or similar, the certificates shall not be accepted.

It is also up to the relying party to study this CPS to decide whether the security level of the issuance process is appropriate for the actual application where to be used.

Telia will provide certificate status information identifying the access point to the CRL or on-line certificate status server in every certificate Telia issues in accordance with this CPS.

9.6.5 Representations and warranties of other participants

Telia will notify Application Software Providers, browsers and/or root stores if a CA private key is suspected to have been compromised.

When a third-party suspect a private key compromise, the third-party shall notify Telia CA according to the information of section 1.5.1.

9.7 Disclaimers of warranties

Telia CA accepts no liability for damages incurred by a relying party accepting one of its certificates, or by a Subscriber whose valid certificate is refused or whose revoked certificate is unduly accepted by a Relying Party. It also accepts no liability for damages arising from the non-issuance of a requested certificate, or for the revocation of a certificate initiated by the CA or the appropriate RA acting in conformance with this CPS.

9.8 Limitations of liability

Telia assumes no liability except as stated in the relevant Subscriber contracts pertaining to certificate issuance and management.

9.9 Indemnities

Telia CA will not pay indemnities for damages arising from the use or rejection of certificates it issues. Subscribers shall indemnify and hold harmless the Telia and all appropriate RAs operating under the applicable CPS against all claims and settlements resulting from fraudulent information provided with the certificate application, and the use and acceptance of a certificate which violates the provisions of this CPS.

Telia CA shall defend, indemnify, and hold harmless each Application Software Supplier for any and all claims, damages, and losses suffered by such Application Software Supplier related to a Certificate issued by Telia CA, regardless of the cause of action or legal theory involved. This does not apply, however, to any claim, damages, or loss suffered by such Application Software Supplier related to a Certificate issued by Telia CA where such claim, damage, or loss was directly caused by such Application Software Supplier’s software displaying as not trustworthy a Certificate that is still valid, or displaying as trustworthy:

1. a Certificate that has expired, or

2. a Certificate that has been revoked (but only in cases where the revocation status is currently available from the CA online, and the application software either failed to check such status or ignored an indication of revoked status).

9.10 Term and termination

9.10.1 Term

This CPS remains in force until notice of the opposite is communicated by Telia on its web site in the Repository.

9.10.2 Termination

Termination of this document will be upon publication of a newer version or replacement document, or upon termination of CA operations.

9.10.3 Effect of termination and survival

The conditions and effect resulting from termination of this document will be communicated, on the Repository, upon termination outlining the provisions that may survive termination of the document and remain in force.

9.11 Individual notices and communications with participants

Telia will define in any applicable agreement the appropriate provisions governing notices.

9.12 Amendments

The PMT is the responsible authority for reviewing and approving changes to this CPS. Written and signed comments on proposed changes shall be directed to the Telia CA Service contact as described in Section 1.5. Decisions with respect to the proposed changes are at the sole discretion of the PMT.

Subscribers will not be notified if the CPS document is changed. When changes are made, they will be published in the Repository for public review and after 15 days will be in effect. Changes to the Telia Group Security Policy will be communicated to third parties, where applicable.

Non normative changes to this CP/CPS (like fixing of broken links, font type face changes, document style corrections / modifications etc.) may be made without executing the said 15 days notice / comment period if approved by PMT according to provisions set forth in this section.

This CPS and Telia Group Security Policy is regularly reviewed and interval between subsequent reviews shall not exceed 365 days.

9.12.1 Procedure for amendment

Changes which shall take place with notification can be made to this CPS 15 days after notification. The PMT will post the notification at the CPS publishing point at the Repository.

PMT decides which measures are taken in relation to the comments received. If comments received necessitate changes to the original change proposal which were not covered by the original notification, these changes may come into force no earlier than 15 days after publication of a new modified notification.

9.12.2 Notification mechanism and period

See 9.12.1

9.12.3 Circumstances under which OID must be changed

If The PMT determines that a new OID is required, PMT will assign a new OID and required amendments will be made.

9.13 Dispute resolution provisions

Before taking any Court action, a party must use best efforts to resolve any dispute under through good faith negotiations. Otherwise, any disputes arising from or relating to this CPS shall be finally settled by arbitration in accordance with the Arbitration Rules of the Finland Chamber of Commerce.

The number of arbitrators shall be one, unless the other party requires that the arbitral tribunal be composed of three members. The place of arbitration is Helsinki, Finland, and the language of the arbitration is Finnish.

Without prejudice to the above, the parties have the right to bring a legal action at the Helsinki District Court when the value of the dispute does not exceed one hundred thousand (100,000) Euros.

9.14 Governing law

This CPS is governed by, and must be interpreted in accordance with, the laws of Finland without regard to the conflict of law provisions.

9.15 Compliance with applicable law

All activities including the request, validation, issuance, use or acceptance of a Telia CA certificate shall comply with Finnish law. Activities initiated from or destined for another country than Finland are also subject to applicable law of that country.

9.16 Miscellaneous provisions

9.16.1 Entire agreement

The interpretation and enforcement requirements in this section are reflected in the applicable Subscriber and Relying Party Agreements.

9.16.2 Assignment

Any entities operating under this CPS may not assign their rights or obligations without the prior written consent of Telia CA.

9.16.3 Severability

If any provision of this CPS is held invalid or unenforceable by a competent court or tribunal, the remainder of the CPS will remain valid and enforceable. Each provision of this CPS that provides for a limitation of liability, disclaimer of a warranty, or an exclusion of damages is severable and independent of any other provision.

In the event of a conflict between these Requirements and a law, regulation or government order (hereinafter ‘Law’) of any jurisdiction in which a CA operates or issues certificates, Telia CA may modify any conflicting requirement to the minimum extent necessary to make the requirement valid and legal in the jurisdiction. This applies only to operations or certificate issuances that are subject to that Law.

If Telia CA chooses to modify requirements as said foregoing chapter, Telia CA shall execute the following:

• Prior to issuing a certificate under the modified requirement

  • include in this Section of this CP/CPS a detailed reference to the Law requiring a modification of these Requirements under this section, and the specific modification to these Requirements implemented by Telia CA.
  • inform CA/Browser forum in accordance with the Baseline Requirements

Any modification to Telia CA practice enabled under this section shall be discontinued if and when the Law no longer applies, or the Baseline Requirements are modified by CA/Browser Forum to make it possible to comply with both them and the Law simultaneously.

An appropriate change in practice, modification to this CP/CPS and a notice to the CA/Browser Forum, as outlined above, shall be made within 90 days.

9.16.4 Enforcement (attorneys’ fees and waiver of rights)

Telia CA may seek indemnification and attorneys' fees from a party for damages, losses, and expenses related to that party's conduct.

9.16.5 Force Majeure

Telia shall not be held responsible for any delay or failure in performance of its obligations hereunder to the extent such delay or failure is caused by fire, flood, strike, civil, governmental or military authority, acts of terrorism or war, sabotage, or other similar causes beyond its reasonable control and without the fault or negligence of Telia or its subcontractors.

9.17 Other provisions

Telia CA as part of the Telia Company adhere with the company level policies such as cybersecurity, privacy and HR. Particularly, the CA aims at providing non-discriminatory services to ensure equal opportunities for persons with disabilities whenever feasible.

Where the breach of security or loss of integrity is likely to adversely affect a natural or legal person to whom the CA service has been provided, the CA will also notify the natural or legal person of the breach of security or loss of integrity without undue delay.