TeliaSonera Public Root CA Certification Practice Statement Public... · Document no 1/011 01-AZDA 102 213 TeliaSonera Sverige AB – Certification Practice Statement – Rev A TeliaSonera

Document no 1/011 01-AZDA 102 213

TeliaSonera Sverige AB – Certification Practice Statement – Rev A

TeliaSonera Public Root CA

Certification Practice Statement

Revision Date: 2006-11-17

Version: Rev A

Published by: TeliaSonera Sverige AB

TeliaSonera Public Root Service CPS

TeliaSonera Sverige AB Page II Doc. no 1/011 01-AZDA 102 213, Rev A

Copyright © TeliaSonera Sverige AB

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

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


TeliaSonera Sverige AB Page III Doc. no 1/011 01-AZDA 102 213, Rev A

Table of Contents Table of Contents ..................................................................................................................III Revision History .................................................................................................................. VII Certification Practice Statement Summary..........................................................................8 1 INTRODUCTION..............................................................................................................9

1.1 Overview...................................................................................................................9 1.2 Document name and identification ...........................................................................9 1.3 PKI participants ........................................................................................................9

1.3.1 Certification authorities ...................................................................................................... 9 1.3.2 Registration authorities ...................................................................................................... 9 1.3.3 Subscribers ........................................................................................................................ 9 1.3.4 Relying parties ................................................................................................................. 10 1.3.5 Other participants............................................................................................................. 10

1.4 Certificate usage.....................................................................................................10 1.4.1 Appropriate certificate uses ............................................................................................. 10 1.4.2 Prohibited certificate uses................................................................................................ 10

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

1.6 Definitions and acronyms .......................................................................................11 2 PUBLICATION AND REPOSITORY RESPONSIBILITIES ...........................................12

2.1 Repositories............................................................................................................12 2.1.1 CPS Repository ............................................................................................................... 12 2.1.2 Revocation information Repository.................................................................................. 12

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

3 IDENTIFICATION AND AUTHENTICATION .................................................................13 3.1 Naming ...................................................................................................................13

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

3.2 Initial identity validation...........................................................................................13 3.2.1 Method to prove possession of private key ..................................................................... 13 3.2.2 Authentication of organization identity............................................................................. 13 3.2.3 Authentication of individual identity.................................................................................. 14 3.2.4 Non-verified subscriber information................................................................................. 14 3.2.5 Validation of authority ...................................................................................................... 14 3.2.6 Criteria for interoperation ................................................................................................. 14

3.3 Identification and authentication for re-key requests ..............................................14 3.3.1 Identification and authentication for routine re-key.......................................................... 14 3.3.2 Identification and authentication for re-key after revocation............................................ 15

3.4 Identification and authentication for revocation request .........................................15 4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS ................................16

4.1 Certificate Application.............................................................................................16 4.1.1 Who can submit a certificate application ......................................................................... 16 4.1.2 Enrollment process and responsibilities .......................................................................... 16

4.2 Certificate application processing...........................................................................16 4.2.1 Performing identification and authentication functions .................................................... 16 4.2.2 Approval or rejection of certificate applications ............................................................... 16


TeliaSonera Sverige AB Page IV Doc. no 1/011 01-AZDA 102 213, Rev A

4.2.3 Time to process certificate applications........................................................................... 16 4.3 Certificate issuance ................................................................................................16

4.3.1 CA actions during certificate issuance............................................................................. 16 4.3.2 Notification to subscriber by the CA of issuance of certificate......................................... 17

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

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

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

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

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

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

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

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

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


TeliaSonera Sverige AB Page V Doc. no 1/011 01-AZDA 102 213, Rev A

4.12.2 Session key encapsulation and recovery policy and practices ................................... 22 5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS .................................23 6 TECHNICAL SECURITY CONTROLS ..........................................................................24 7 CERTIFICATE, CRL, AND OCSP PROFILES ..............................................................25

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

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

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

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

9 OTHER BUSINESS AND LEGAL MATTERS ...............................................................28 9.1 Fees........................................................................................................................28

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

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

9.3 Confidentiality of business information ...................................................................28 9.3.1 Scope of confidential information..................................................................................... 28 9.3.2 Information not within the scope of confidential information............................................ 29 9.3.3 Responsibility to protect confidential information ............................................................ 29

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

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

9.6.1 CA representations and warranties ................................................................................. 30 9.6.2 RA representations and warranties ................................................................................. 31 9.6.3 Subscriber representations and warranties ..................................................................... 31 9.6.4 Relying party representations and warranties ................................................................. 31 9.6.5 Representations and warranties of other participants ..................................................... 32

9.7 Disclaimers of warranties........................................................................................32


TeliaSonera Sverige AB Page VI Doc. no 1/011 01-AZDA 102 213, Rev A

9.8 Limitations of liability...............................................................................................32 9.9 Indemnities .............................................................................................................32 9.10 Term and termination..............................................................................................32

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

9.11 Individual notices and communications with participants .......................................32 9.12 Amendments ..........................................................................................................33

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

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

9.16.1 Entire agreement ......................................................................................................... 34 9.16.2 Assignment.................................................................................................................. 34 9.16.3 Severability .................................................................................................................. 34 9.16.4 Enforcement (attorneys’ fees and waiver of rights)..................................................... 34 9.16.5 Force Majeure ............................................................................................................. 34

9.17 Other provisions......................................................................................................34 Acronyms and Definitions...................................................................................................35

Acronyms ...........................................................................................................................35 Definitions...........................................................................................................................36


TeliaSonera Sverige AB Page VII Doc. no 1/011 01-AZDA 102 213, Rev A

Revision History Version Version date Change Author A 2006-11-17 First version of the TeliaSonera Public

Root CPS. Approved by the TeliaSonera CPS Management Team.

Petter Ljunggren Stefan Jacobsson Peter Döös


TeliaSonera Sverige AB Page 8 Doc. no 1/011 01-AZDA 102 213, Rev A

Certification Practice Statement Summary This document defines the Certification Practice Statement for the TeliaSonera Public Root CA. The TeliaSonera Public Root CA will sign and issue certificates to TeliaSonera customers. A customer to TeliaSonera will host their CA at the TeliaSonera site or be a part of the TeliaSonera Managed CA Services. Any CA chained to the TeliaSonera Public Root CA shall and will confirm to this CPS, the TeliaSonera Public Root CP and the RSA RSS CP. This document is intended for users, relying parties, customers and organizations that are interested in the TeliaSonera Public Root Services and how TeliaSonera conduct their CA Services in accordance with the RSA RSS CP. The TeliaSonera Public Root CPS generally conforms to the IETF PKIX Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practice Statement Framework (also known as RFC 3647). 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.



1 INTRODUCTION 1.1 Overview This CPS describes the procedures and routines which apply when completing a certificate for individuals, organizations, functions and devices and for revoking and revocation checking of such certificates. The CPS describes TeliaSonera’s application of the requirements and regulations in RSA Root Signing Service Certificate Policy.

1.2 Document name and identification The routines and roles resulting from this CPS apply only in connection with certificates referring to the TeliaSonera Public Root Certificate Policy or RSA Root Signing Service Certificate Policy. The object identifier of the RSA Root Signing Service Certificate Policy (OID) is {1.2.840.113549.5.6.1}. The policy name of the TeliaSonera Public Root Certificate Policy is {SE-TELIASONERA-PUBLICROOT-POLICY-1} and the object identifier (OID) is {1.2.752.35.2.1.1}. The CPS name of this CPS is {SE-TELIASONERA-PUBLICROOT-CPS-1} and the object identifier is {1.2.752.35.2.2.1}. The TeliaSonera document number of this CPS is 1/011 01-AZDA 102 213. This CPS also refers to the TeliaSonera Production CPS with the name {SE-TELIASONERA-EID-CPS-1} and the object identifier {1.2.752.35.8.2.1}.

1.3 PKI participants TeliaSonera will issue certificates mainly to customers of TeliaSonera but also to TeliaSonera employees. All of the participating organizations will have their CA hosted by TeliaSonera and all organizations shall undertake what’s stated in the TeliaSonera Public Root CP and this CPS.

1.3.1 Certification authorities TeliaSonera manages a PKI under the RSA RSS CP. The TeliaSonera Root CA signs sub CA certificates to organizations that contractually will adhere to this CPS and to TeliaSonera Public Root CP or to TeliaSonera Service sub CA’s CP. The TeliaSonera Public Root CA is responsible for managing the certificate life cycle of CAs signed by the TeliaSonera Public Root and end entity certificates signed by the sub CAs. This will include:

• creating and signing of certificates binding Subscribers, and PKI personnel with their public encryption key.

• promulgating certificate status through CRLs and/or OCSP responders; and • creating, storing and recovering end entity confidential key pairs for organizations using the

TeliaSonera key backup/restore service; • requiring adherence to RSA RSS CP and this CPS.

1.3.2 Registration authorities An RA Administrator or Vettor operating under this CPS is responsible for all duties assigned to it by the issuing CA. An RA Administrator or Vettor may perform duties on behalf of more than one CA, providing that in doing so it satisfies all requirements of this TeliaSonera Public Root CP and it is not otherwise contractually prohibited from doing so.

1.3.3 Subscribers A subscriber may be:



• an organization that is a customer of TeliaSonera hosting their CA at TeliaSonera. • an individual employed by TeliaSonera or employed by a customer to TeliaSonera. An

individual that is a customer of TeliaSonera • a device situated at TeliaSonera or at a customer to TeliaSonera. • a function at TeliaSonera or at a customer to TeliaSonera

1.3.4 Relying parties A Relying Party may be either a Subscriber of any TeliaSonera CA or any other organization, person, application or device that is relying on a certificate issued by a CA that is chained to the TeliaSonera Public Root CA.

1.3.5 Other participants No stipulation

1.4 Certificate usage

1.4.1 Appropriate certificate uses Certificates issued under this CPS can be used for many various applications like business transactions (server to server), encrypted and signed emails (S/MIME) and other applications where the need for integrity, authenticity and confidentiality is a strong requirement.

1.4.2 Prohibited certificate uses It is not recommended to use certificates for encryption if the private key of the certificate is not backed up.

1.5 Policy administration

1.5.1 Organization administering the document TeliaSonera CPS Management Team is the responsible authority for reviewing and approving changes to the TeliaSonera Public Root CPS. Written and signed comments on proposed changes shall be directed to the TeliaSonera contact as described in Section 1.5.2. Decisions with respect to the proposed changes are at the sole discretion of the TeliaSonera CPS Management Team.

1.5.2 Contact person Any questions relating to this CPS should be sent in writing to: TeliaSonera Sverige AB Customer Service Box 352 831 25 Östersund, Sweden Telephone: +46 (0)20 32 32 62 E-mail: [email protected] Web: www.telia.se

1.5.3 Person determining CPS suitability for the policy RSA ROOT SIGNING SERVICE is the administrative entity for determining this Certification Practice Statement (CPS) suitability to the RSA RSS CP.

1.5.4 CPS approval procedures The RSA ROOT SIGNING SERVICE will review any modifications, additions or deletions from all CPS’s that are obligated to be compliant with the RSA RSS CP, TeliaSonera CPS Management Team will review any modifications, additions or deletions from all CPS’s that are obligated to be compliant with the TeliaSonera Public Root CP, and determine if modifications, additions or deletions are acceptable and do not jeopardize operations or the security of the CA environment.



1.6 Definitions and acronyms A list of definitions and acronyms can be found at the end of this document.



2 PUBLICATION AND REPOSITORY RESPONSIBILITIES 2.1 Repositories

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

2.1.2 Revocation information Repository Certificate Revocation Lists are published in an LDAP directory ldap://ldap.trust.telia.com. OCSP request can be made to http://ocsp.trust.telia.com. In general OCSP requests need to be signed, i.e. a relying party who wants to validate certificates by OCSP needs to make an agreement with TeliaSonera.

2.2 Publication of certification information It is TeliaSonera’s duty to make the following information available. a) This CPS. b) Certificate Revocation lists of revoked certificates or revocation information via OCSP if agreed. c) Issued CA certificates. TeliaSonera may publish and supply certificate information in accordance with applicable legislation. Each published certificate revocation list (CRL) provides all available revocation information at the time of publication for all revoked certificates of which the revocation list is intended to give notification. TeliaSonera 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 Revocation information of issued CA certificates will be published promptly or at least within 24 hours. Revocation information of issued end entity certificates will be published promptly or at least within 3 hours. Publication of revocation information may differ from the above if so agreed with a customer to TeliaSonera.

2.4 Access controls on repositories This CPS is publicly available. CRLs are publicly available through the TeliaSonera LDAP directory. OCSP services are only available through an agreement with TeliaSonera.



3 IDENTIFICATION AND AUTHENTICATION 3.1 Naming

3.1.1 Types of names The name of the certificate holder will reside within the certificate subject distinguished name. The certificate subject name field in will be in accordance with PKIX Part 1 and will be in the form of a X.501 printableString or UTF8String and will not be blank. The name will differ dependent on the application the certificate is used for. Examples of names are: legal names of individuals and organizations, domain names, email addresses, social security numbers, employee numbers.

3.1.2 Need for names to be meaningful Individual certificates: A certificate for an individual will contain the legal name of the subscriber. Server/Device certificates: A certificate for a server or a device will contain the domain name of the server or the unique name of the device. Organizational certificates: A certificate for an organization will contain the legal name of the organization or a trademark tied to that organization.

3.1.3 Anonymity or pseudonymity of subscribers No stipulation.

3.1.4 Rules for interpreting various name forms No stipulation.

3.1.5 Uniqueness of names Within a CA the DN of the subscriber is unique. For individuals, if uniqueness cannot be achieved by the legal name, the subject DN in the certificate will contain a unique name such as employee number or social security number.

3.1.6 Recognition, authentication, and role of trademarks The priority to entity names are given to registered trademark holders. The use of a Domain Name is restricted to the authenticated legal owner of that Domain Name. The use of an email address is restricted to the authenticated legal owner of that email address. TeliaSonera will validate an organizations right to use a specified name, domain name and trademark.

3.2 Initial identity validation

3.2.1 Method to prove possession of private key Method to prove possession of private key is PKCS#10 or CRS (Certificate Request Syntax).

3.2.2 Authentication of organization identity An application for an organization to become a Subscriber is made by a person authorized to act on behalf of the organization. The application includes details about the organization and includes a certified true copy of their incorporation papers. TeliaSonera will verify the identity of the individual making the application and their authority to receive the keys for that organization.



TeliaSonera will keep a record of the type and details of the identification used for the authentication of the organization for at least the life of the issued certificate.

3.2.3 Authentication of individual identity An application for an individual to be a Subscriber will be made by the individual, or by another person or organization authorized to act on behalf of the prospective Subscriber. Background checks will be performed by TeliaSonera. TeliaSonera will keep a record of the type and details of identification used for the authentication of the individual for at least the life of the issued certificate. Identification and authentication of a prospective Subscriber will be through one of the following means:

1. In person where the TeliaSonera or an RA appointed by TeliaSonera will compare the identity of the individual with a picture identification (notarized copies or originals); or

2. On-line where the Subscriber agrees to the terms and conditions of an on-line Subscriber Agreement, the Subscriber completes an on-line form and TeliaSonera or a RA appointed by TeliaSonera performs an out-of-band validation check on the information submitted. The out-of-band validation will be performed in different ways depending on the entity that shall be validated. If TeliaSonera or a customer to TeliaSonera has a previously established identity check of the subscriber which meets the requirements of 1 or 2, certified key pairs, shared secrets or equivalent authentication mechanism can be used.

For further information regarding the methods used see the CPS’s of the different services and customer CAs residing under the TeliaSonera Public Root Service.

3.2.4 Non-verified subscriber information All non-verified subscriber information will be specified in the CPS of each sub CA signed by the TeliaSonera Public Root CA.

3.2.5 Validation of authority An application for a certificate will be made by an individual that is accountable and responsible for the component participating in the service. TeliaSonera or an RA, on behalf of TeliaSonera, will validate that the following have been verified:

• The identity of the individual making the application, • The validity of that organization’s business relationship with TeliaSonera, and • The authority of the individual to receive the certificate(s) for that organization application

service.

3.2.6 Criteria for interoperation Not applicable. Cross certification will not be a service within this CPS.

3.3 Identification and authentication for re-key requests

3.3.1 Identification and authentication for routine re-key Routine re-key is not supported. Prior to the expiry of a private key, a request for a re-key will only be made by the entity in whose name the keys have been issued. An issuing CA will authenticate all requests for re-key, and the subsequent response will be authenticated by the entity. An entity requesting re-key will authenticate the request for re-key using a digital signature generated with the private key corresponding to the certified public key. Where the digital signature private key has expired, the request for re-key will be authenticated in the same manner as the initial registration. In the case where there is a shared secret, the issuing CA will re-authenticate the Subscriber using the shared secret. In all cases re-key requires the replacement of the public key in the certificate. A new public/private key pair is generated and a new certificate is issued.



3.3.2 Identification and authentication for re-key after revocation Where the information contained in a certificate has changed or there is a known or suspected compromise of the private key resulting in a revocation, TeliaSonera or an RA will authenticate a re-issuance in the same manner as for initial registration pursuant to Section 3.2. TeliaSonera will verify any change in the information contained in a certificate before the certificate is issued.

3.4 Identification and authentication for revocation request An authentication request for revocation will be done in one of the following manners:

• The key-holder makes a call to customer service to revoke the certificate. • The key-holder uses a self administration GUI to revoke the certificate. • TeliaSonera or an RA appointed by TeliaSonera will, if there is a suspicion of a compromised

certificate; revoke the certificate on behalf of the key-holder. TeliaSonera will keep a record of all revocation requests. The record will hold information of the identity of the requesting person, the identity of the administrator revoking the certificate and the time the revocation was done. The records are included in the audit logs of the RA systems at TeliaSonera production facilities. For further information regarding the records see the TeliaSonera Production CPS section 5.4 and 5.5.



4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1 Certificate Application

4.1.1 Who can submit a certificate application An organization that has agreed to and executed an Agreement with TeliaSonera, and meets the requirements of the TeliaSonera Public Root Certificate Policy can have a hosted CA at the TeliaSonera site. The customer hosting their CA at TeliaSonera will only issue certificates to employees, devices, functions or servers within their organization or to a subscriber that has a valid contract with the organization and has a valid business relationship with the organization and are bound to comply with provisions of such business relationship and any applicable agreement or corporate policies. All subscriber information will be complete, validated and accurate with full disclosure of all required information in connection with a certificate request.

4.1.2 Enrollment process and responsibilities Subscribers registering for a certificate from a CA will be required to consent to an agreement with TeliaSonera, either at the time of registration or upon certificate acceptance.

4.2 Certificate application processing TeliaSonera will require that each application be accompanied by:

1. Proof of end entity identity; 2. Proof of authorization for any requested certificate attributes; 3. A signed agreement of the applicable terms and conditions governing the applicants use of

the certificate; and 4. A public verification key generated by the end entity.

In some occasions when keys and certificates reside on a smart card TeliaSonera will generate the public key on behalf of the entity.

4.2.1 Performing identification and authentication functions TeliaSonera or an RA appointed by TeliaSonera will always identify and validate the certificate application. How identification and validation is done will depend on the basis of the pre-identification made by a customer and will be a part of the agreement with the customer.

4.2.2 Approval or rejection of certificate applications TeliaSonera or an RA appointed by TeliaSonera 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 told why the certificate application was rejected and how to proceed to be approved.

4.2.3 Time to process certificate applications Processing time of a certificate application will differ depending on the steps taken in the validation plan. A certificate application in an automated process, the certificate will be issued promptly while a certificate application in a manual process, the certificate will be issued when the validation is done.

4.3 Certificate issuance

4.3.1 CA actions during certificate issuance An approved certificate application will result in an issued certificate. An issued certificate will be delivered to the subscriber promptly or it will be delivered to the subscriber on a smartcard. In general, issued certificates will not be published to a public available repository.



In specific cases certificates will be published to an internal directory of a customer depending on the agreement with the customer to TeliaSonera.

4.3.2 Notification to subscriber by the CA of issuance of certificate The subscriber will be notified when the certificate is issued. This will be done depending on the application the certificate will be used for. Notification will be done via email, mail, telephone or promptly via the web depending on the issuing/application process.

4.4 Certificate acceptance

4.4.1 Conduct constituting certificate acceptance By accepting and using the certificate the Subscriber agrees to comply with the terms of any policies and CPS’s referenced within the certificate. The relevant CP and CPS will be defined in the CPS’s of the different services and customers CAs residing under the TeliaSonera Public Root Service.

4.4.2 Publication of the certificate by the CA TeliaSonera will publish all CA certificates in the LDAP repository. TeliaSonera will not publish subscriber certificates to a public available repository if it’s not agreed with the customer or subscriber. Publication will be done to internal directories or databases at the TeliaSonera site or at the customer site.

4.4.3 Notification of certificate issuance by the CA to other entities No stipulation.

4.5 Key pair and certificate usage

4.5.1 Subscriber private key and certificate usage The Subscriber will only use certificates, issued under the TeliaSonera Public Root CA, and their associated key pairs for the purposes identified in the TeliaSonera Public Root CP and identified in the agreement with TeliaSonera.

4.5.2 Relying party public key and certificate usage Prior to using a Subscriber's certificate, a Relying Party should verify that the certificate is appropriate for the intended use.

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. TeliaSonera will only renew CA-certificates. TeliaSonera will not renew certificates to end user subscribers.

4.6.1 Circumstance for certificate renewal An organization that has a valid certificate with a shorter validity period than 10 years may extend the validity of the CA up to 10 years.

4.6.2 Who may request renewal An organization that has a valid agreement with TeliaSonera and a valid CA certificate issued under the TeliaSonera Public Root service may request for renewal.

4.6.3 Processing certificate renewal requests Renewal will be processed according to customer agreement.



4.6.4 Notification of new certificate issuance to subscriber Notification will be processed according to customer agreement.

4.6.5 Conduct constituting acceptance of a renewal certificate No stipulation.

4.6.6 Publication of the renewal certificate by the CA The renewed certificate will be published in TeliaSonera LDAP repository (ldap://ldap.trust.telia.com) and according to the relevant customer agreement.

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

4.7 Certificate re-key

4.7.1 Circumstance for certificate re-key A re-key request will only be approved if the certificate has yet not expired. In general a subscriber will be notified within 30 days of certificate expiry and asked to make a re-key request using the private key connected to the certificate.

4.7.2 Who may request certification of a new public key An organization with a valid agreement with TeliaSonera can request certification of a new public key. An RA with a valid agreement with TeliaSonera can request certification of a new public key. A subscriber with a valid certificate can request certification of a new public key.

4.7.3 Processing certificate re-keying requests TeliaSonera will validate the existing name in the certificate against a corporate directory/database or other database containing information about the subscriber. This process is handled by RA personnel at TeliaSonera or at customers of TeliaSonera. The re-keying process may also be implemented as an automated process. A new certificate will be issued if the subscriber succeeds to make a positive identification and if the validation check does not fail. The identification and authentication processes regarding re-keying are described in section 3.3.1 and further described in the CPS’s of the different services and customer CAs residing under the TeliaSonera Public Root Service.

4.7.4 Notification of new certificate issuance to subscriber The subscriber will be notified when the certificate is issued. This will be done depending on the application the certificate will be used for. Notification will be done via email, mail, telephone or promptly via the web depending on the issuing/application process.

4.7.5 Conduct constituting acceptance of a re-keyed certificate By accepting and using the certificate the Subscriber agrees to comply with the terms of any policies referenced within the certificate.

4.7.6 Publication of the re-keyed certificate by the CA TeliaSonera will publish all CA certificates in the LDAP repository. TeliaSonera will not publish subscriber certificates to a public available repository if it’s not agreed with the customer or subscriber. Publication will be done to internal directories or databases at the TeliaSonera site or at the customer site.




4.8 Certificate modification Certificate modification is not supported by TeliaSonera.

4.8.1 Circumstance for certificate modification Not applicable.

4.8.2 Who may request certificate modification Not applicable.

4.8.3 Processing certificate modification requests Not applicable.

4.8.4 Notification of new certificate issuance to subscriber Not applicable.

4.8.5 Conduct constituting acceptance of modified certificate Not applicable.

4.8.6 Publication of the modified certificate by the CA Not applicable.


4.9 Certificate revocation and suspension

4.9.1 Circumstances for revocation A certificate will be revoked:

1. When any information in the certificate changes; 2. Upon suspected or known compromise of the private key; 3. Upon suspected or known compromise of the media holding the private key; 4. Upon termination of a Subscriber; or 5. When a Subscriber no longer needs access to secured organizational resources.

TeliaSonera or an RA appointed by TeliaSonera in its discretion will revoke a certificate when an entity fails to comply with obligations set out in the TeliaSonera Public Root CP, this CPS, any applicable agreement or applicable law. TeliaSonera will revoke a certificate at any time if TeliaSonera suspects that conditions may lead to a compromise of a Subscriber’s keys or certificates.

4.9.2 Who can request revocation The revocation of a certificate will be requested by:

1. A Subscriber whose name the certificate is issued under; 2. An individual or organization that has made an application for a certificate on behalf of an

organization, device or application; 3. Personnel of an RA associated with TeliaSonera; or 4. Personnel of TeliaSonera.

4.9.3 Procedure for revocation request A revocation request may be received by TeliaSonera in one of the three following ways: a) The RA makes the revocation request using the administration interface and signs this with a digital signature. b) The key holder makes the revocation request using a self-administration interface and signs this with a digital signature using TeliaSonera eID or other equivalent certificate from an issuer approved by TeliaSonera.



c) If the revocation request cannot be carried out in accordance with a) or b), the RA, the authorized representative of the RA or the key holder may contact TeliaSonera Customer Service by telephone and make a revocation request. Authorized TeliaSonera Customer Service staff, or another authorized function within TeliaSonera, then makes the revocation request using TeliaSonera’s CA system and signs this with a digital signature. When making a revocation request as above, TeliaSonera’s CA system checks that the digital signature on the revocation request is valid and that the person signing the revocation request is authorized to do so. If both these criteria are met, the certificate in question is revoked. TeliaSonera will keep records of all revocation requests. The records will hold information of the identity of the requesting person, the identity of the administrator revoking the certificate and the time the revocation was done. For further information regarding the records see the TeliaSonera Production CPS section 5.4 and 5.5.

4.9.4 Revocation request grace period On suspicion of a certificate being compromised or a certificate in any other way no longer is relevant for usage, the certificate subscriber must immediately make a revocation request for the certificate to TeliaSonera or any other RA appointed for the relevant service.

4.9.5 Time within which CA must process the revocation request The process of handling a revocation request will take maximum 1 hour.

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 certificate status server (OCSP). A Relying Party is also responsible for verifying the authenticity and integrity of CRL’s or on-line certificate status responses. TeliaSonera will provide certificate status information identifying the access point to the CRL or on-line certificate status server in every certificate TeliaSonera issues.

4.9.7 CRL issuance frequency In general CRL’s are issued once every hour with the latest revocation information. However the nextUdate parameter in the CRL is normally set to 24 hours. For CA’s hosted at the TeliaSonera site, update frequency of CRL’s will be agreed upon with each customer and stated in their CPS.

4.9.8 Maximum latency for CRL’s CRL’s are published to the TeliaSonera LDAP directory and updated immediately. Latency will be a matter of seconds.

4.9.9 On-line revocation/status checking availability TeliaSonera provides on-line revocation status checking via the OCSP protocol. The service is only accessible provided that the relying party has an agreement with TeliaSonera. Availability of the service will be provided in the agreement.

4.9.10 On-line revocation checking requirements In general all OCSP requests 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. A separate key pair will be used for the responses of each CA. The OCSP service is updated through the use of CRLs and deltaCRLs that are published on regular basis. The actual time intervals for the updates of the CRLs and deltaCRLs are described in the CPS’s of the different services and customer CAs residing under the TeliaSonera Public Root Service.

4.9.11 Other forms of revocation advertisements available No stipulation.



4.9.12 Special requirements re-key compromise No stipulation.

4.9.13 Circumstances for suspension TeliaSonera does not support suspension of certificates.

4.9.14 Who can request suspension Not applicable.

4.9.15 Procedure for suspension request Not applicable.

4.9.16 Limits on suspension period Not applicable.

4.10 Certificate status services

4.10.1 Operational characteristics Address to LDAP repository: Domain Name: ldap.trust.telia.com Port number: 389 Search base for attribute certificateRevocationList: <issuer DN of CA>

4.10.2 Service availability SLA is not a part of this CPS.

4.10.3 Optional features No stipulation.

4.11 End of subscription The end of a subscription as a result 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 CA Private Signing Keys will not be escrowed. A Subscriber’s digital signature private keys will not be escrowed. A Subscriber’s confidentiallity private keys will be not be escrowed but TeliaSonera may keep a backup of the keys if so agreed between TeliaSonera and the customer. The keys are protected in an encrypted form and are protected in 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 a HSM and the key backups are saved for a period that is agreed with the customer. A private key may be recovered for two separate reasons:

a) 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 is recovered the certificate for the corresponding public key is automatically revoked, a new key pair is created and a new certificate is issued.

b) The Subscriber is for some reason prevented from using his private key (the Subscriber may for instant be deceased, injured or has left the organization) and the Subscriber’s organization needs to decrypt data encrypted by the Subscriber. The process of such a key recovery involves at least three persons from the Subscribers’ organization where all are authenticated



by certificates. When a private key is recovered the certificate for the corresponding public key is automatically revoked.

More information regarding the processes for backup/recovery will be found in the CPS’s of the different services and customer CAs residing under the TeliaSonera Public Root Service..

4.12.2 Session key encapsulation and recovery policy and practices No stipulation.



5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

All stipulations regarding chapter 5 Facility Management, and Operational Control are specified in “TeliaSonera Production CPS”.



6 TECHNICAL SECURITY CONTROLS All stipulations regarding chapter 6 Technical Security Controls are specified in “TeliaSonera Production CPS”.



7 CERTIFICATE, CRL, AND OCSP PROFILES 7.1 Certificate 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 extensions Certificate extensions will be supported in accordance with RFC 3280 “Internet X.509 Public Key Infrastructure Certificate and CRL Profile” dated April 2002. Standard Certificate Extensions Authority Key Identifier Subject Key Identifier Key Usage Certificate Policies Policy Mappings Subject Alternative Name Issuer Alternative Names Subject Directory Attributes Basic Constraints Name Constraints Policy Constraints Extended Key Usage CRL Distribution Points Freshest CRL Authority Information Access Subject Information Access Private Certificate Extension For issued smart cards one private extension is used to indicate the card serial number. The SEIS Card Number extension contains the ISO 7812 serial number of an EID card in a printable string. The OID of the SEIS Card Number extension is 1.2.752.34.2.1. The Card Number extension is set as non-critical.

7.1.3 Algorithm object identifiers At least the following algorithms are supported for signing and verification:

1. RSA 1024 algorithm in accordance with PKCS#1; and/or 2. SHA-1 algorithm in accordance with FIPS PUB 180-1 and ANSI X9.30 part2; and/or 3. Additional algorithms as supported by TeliaSonera CA-Services.

7.1.4 Name forms Every DN will be in the form of an X.501 DirectoryString.

7.1.5 Name constraints Subject and Issuer DNs comply with PKIX standards and are present in all certificates.

7.1.6 Certificate policy object identifier The certificate policy object identifier will be present in issued certificates.

7.1.7 Usage of Policy Constraints extension No stipulation.



7.1.8 Policy qualifiers syntax and semantics No stipulation.

7.1.9 Processing semantics for the critical Certificate Policies extension No stipulation.

7.2 CRL profile

7.2.1 Version number(s) All issued CRL’s are X.509 version 2 CRL’s in accordance with the RFC 3280 “Internet X.509 Public Key Infrastructure Certificate and CRL Profile” dated April 2002.

7.2.2 CRL and CRL entry extensions CRL extensions will be supported in accordance with RFC 3280 “Internet X.509 Public Key Infrastructure Certificate and CRL Profile” dated April 2002. Standard CRL Extensions: Authority Key Identifier Issuer Alternative Name CRL Number Delta CRL Indicator Issuing Distribution Point Freshest CRL CRL Entry Extensions In general Authority Key Identifier extension, CRL Number extension and the Reason Code of the CRL Entry extension will be included in a CRL.

7.3 OCSP profile

7.3.1 Version number(s) Version 1 of the OCSP specification as defined by RFC2560 (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol) is implemented for the OCSP responders.

7.3.2 OCSP extensions OCSP Nonce extension should be used in requests.



8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS 8.1 Frequency or circumstances of assessment An annual Compliance Audit will be performed by an independent, qualified third party.

8.2 Identity/qualifications of assessor The Compliance Auditor must demonstrate competence in the field of compliance audits, and must be thoroughly familiar with the requirements which a CA service imposes on the issuance and management of certificates. The Compliance Auditor should perform such compliance audits as a primary responsibility.

8.3 Assessor's relationship to assessed entity The Compliance Auditor should not have any financial, legal or organizational relationship with the audited party. A person cannot be Compliance Auditor if he/she:

a. is owner to or joint owner to TeliaSonera or another company within the same group. b. is a member of the TeliaSonera management or the management of any subsidiary, or assists

with TeliaSonera’s bookkeeping or management of means, or TeliaSonera’s control of them, or managing the issues regarding information security.

c. is employed by or in other aspects in subordinate or dependant relation to TeliaSonera or any other company referred to in a) and b) above,

d. is married to or co-habiter with or is sibling or close relative to a person that is referred to in a) and b) above, or

e. is in debt to TeliaSonera or any other company referred to in a) to c) above.

8.4 Topics covered by assessment The purpose of the Compliance Audit is to verify that TeliaSonera and all engaged subcontractors are complying with the requirements of this CPS. The Compliance Audit will cover all requirements that define the operation of a CA under this CPS including:

a. The CA production integrity (key and certificate life cycle management); and b. CA environmental controls.

8.5 Actions taken as a result of deficiency Depending on the severity of the deficiency, the following actions may be taken:

a. The Compliance Auditor may note the deficiency as part of the report; b. The Compliance Auditor may meet with TeliaSonera 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 this CPS;

c. The Compliance Auditor may report the deficiency and if the TeliaSonera Public Root Service deems the deficiency to have risk to the operation of the TeliaSonera or customers CAs, the TeliaSonera Public Root Service operator may revoke the CA’s certificate.

Should this 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 Compliance Auditor shall provide the TeliaSonera Public Root Service management with a copy of the results of the Compliance Audit. The results will not be made public unless required by law.



9 OTHER BUSINESS AND LEGAL MATTERS 9.1 Fees Fees are defined in applicable customer 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 See section 9.1.

9.2 Financial responsibility TeliaSonera and all CAs residing under the TeliaSonera Public Root CA will maintain adequate levels of insurance necessary to support its business practices.

9.2.1 Insurance coverage TeliaSonera and all CAs residing under the TeliaSonera Public Root CA will maintain, at its own expense, insurance of the type and with the limits agreed upon within the RSA Root Signing Agreement.

9.2.2 Other assets No stipulation.

9.2.3 Insurance or warranty coverage for end-entities RSA Root Signing Service is not a trustee, agent, fiduciary, or other representative of the Subscriber and the relationship between the RSA Root Signing Service and the Subscriber is not that of an agent and a principal. RSA Root Signing Service makes no representation to the contrary, either implicitly, explicitly, by appearance or otherwise. The Subscriber does not have any authority to bind RSA Root Signing Service by contract, agreement or otherwise, to any obligation. TeliaSonera is not a trustee, agent, fiduciary, or other representative of the Subscriber and the relationship between the TeliaSonera and the Subscriber is not that of an agent and a principal. TeliaSonera makes no representation to the contrary, either implicitly, explicitly, by appearance or otherwise. The Subscriber does not have any authority to bind TeliaSonera by contract, agreement or otherwise, to any obligation.

9.3 Confidentiality of business information

9.3.1 Scope of confidential information Information which is not excluded in section 9.3.2, or otherwise defined as public in this CPS or in applicable policy, shall be treated as confidential and not be disclosed without the consent of the key holders or agreement parties involved. An example of confidential information is:

a. Personal and corporate information, not appearing in certificates and in public directories, held by a CA or an RA (e.g. registration and revocation information, logged events, correspondence between Subscriber and CA)



b. Audit information Any request for the disclosure of information shall be signed and delivered in writing to the issuing Certification Authority. Any disclosure of information is subject to the requirements of Swedish privacy laws.

9.3.2 Information not within the scope of confidential information The following information is not deemed to be confidential:

a. Issued certificates including public keys b. Revocation lists and OCSP responses c. Key holder terms and conditions d. This CPS e. Information that is documented by the receiving party as having been independently developed

by it without unauthorized reference to or reliance on the confidential information of the disclosing party

f. Information that the receiving party lawfully receives free of restriction from a source other than the disclosing party

g. Information that is or becomes generally available to the public through no wrongful act or omission on the part of the receiving party;

h. Information that at the time of disclosure to the receiving party was known to the receiving party free of restriction as evidenced by documentation in the receiving party’s possession; or

i. Information that the disclosing party agrees in writing is free of restrictions. 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 from unauthorized 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 TeliaSonera, 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 authorized representative of the issuing CA. TeliaSonera will disclose confidential information if a court or other legal authority subject to Swedish law so decides. Private keys linked to issued certificates cannot be supplied where these are not stored by TeliaSonera or any of TeliaSonera’s subcontractors.

9.4 Privacy of personal information

9.4.1 Privacy plan TeliaSonera will not disclose any personal information as long as the information is not considered public and unless it is not required by law. In general all information not stated in 9.4.3 is treated as private and will not be disclosed by TeliaSonera without the consent of the subscriber or the subscriber’s organization.

9.4.2 Information treated as private TeliaSonera will treat the following information as being private:

a) Registration information. b) Correspondence between TeliaSonera and the subscriber. c) Logged events.

9.4.3 Information not deemed private Publicly available information such as:

a) Certificates in publicly available directories. b) Certificate serial numbers in publicly available CRL’s. c) Other information regarded as being public.



is not considered as being private personal information.

9.4.4 Responsibility to protect private information See section 9.3.3.

9.4.5 Notice and consent to use private information Private personal information will only be utilized without prior consent as per section 9.4.1.

9.4.6 Disclosure pursuant to judicial or administrative process Private personal information will only be disclosed if required by law as per section 9.4.1. Any request for the disclosure of private information will be signed by the requester and delivered in writing to TeliaSonera or an RA appointed by TeliaSonera. Any disclosure of private information is subject to the requirements of Swedish privacy laws and applicable organizational policy.

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. In accordance with the Swedish Copyright Act, 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 TeliaSonera Sverige 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: Organization: TeliaSonera Sverige AB Department: Customer Service Box 352 831 25 Östersund, Sweden Telephone: +46 (0)20 32 32 62 E-mail: [email protected]

9.6 Representations and warranties A CA will issue and revoke certificates, operate its certification and repository services, and provide certificate status information in accordance with this CPS. Authentication and validation procedures will be implemented as set forth in Section 3 of this CPS

9.6.1 CA representations and warranties TeliaSonera will operate in accordance with this CPS, when issuing and managing certificates provided to CAs, RAs, sub-CAs and Subscribers. TeliaSonera and all CAs residing under the TeliaSonera Public Root CA will require that all the RAs operating on their behalf will comply with the relevant provisions of this CPS concerning the operations of the RAs. and all CAs residing under the TeliaSonera Public Root CA will take commercially reasonable measures to make Subscribers and Relying Parties aware of their respective rights and obligations with respect to the operation and management of any keys, certificates or End-Entity hardware and software used in connection with the PKI. Subscribers will be notified as to procedures for dealing with suspected key compromise and service cancellation. When a CA publishes or delivers a certificate, it declares that it has issued a certificate to a Subscriber and that the information stated in the certificate was verified in accordance with this CPS.



CA personnel associated with PKI roles will be individually accountable for actions they perform. "Individually accountable" means that there shall be evidence that attributes an action to the person performing the action. All CA personnel are provided with a smart card which gives access when performing any actions in the CA applications. The audit logs are the main tool to control any misuse of the CA personnel’s authorities. For the processes authenticating the CA personnel see TeliaSonera Production CPS section 5.

9.6.2 RA representations and warranties TeliaSonera and all CAs residing under the TeliaSonera Public Root Service will require that all of its RA Administrators and Vettors comply with all the relevant provisions of this CPS. The RA Administrator or Vettor is responsible for the identification and authentication of Subscribers following section 3.1 and section 4.1. TeliaSonera and all CAs residing under the TeliaSonera Public Root CA will through their RA personnel make available Subscriber Agreements and/or role descriptions to Subscribers. The Subscriber Agreements and role descriptions shall contain all relevant information pertaining the rights and obligations of the CA Administrators, RA Administrators, Vettors and Subscribers contained in this CPS. The RA Administrator or Vettor is responsible for revoking certificates in accordance with the CPS. RAs 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 particular 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 authorized 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 this CPS. The information about how such a certificate request shall be made is described in the CPS’s of the different services and customer CAs residing under the TeliaSonera Public Root Service. All RA personnel are provided with a smart card which gives access 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 TeliaSonera Production CPS section 5.

9.6.3 Subscriber representations and warranties TeliaSonera and all CAs residing under the TeliaSonera Public Root Service will require that its 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, in accordance with the Subscriber Agreement and the CPS of the relevant service, and to take all commercially reasonable measures to prevent their loss, disclosure, modification, or unauthorized 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 this CPS and in any applicable agreement(s). When a Subscriber suspects a private key compromise, the Subscriber shall notify the issuing Certification Authority in the manner specified in this CPS. When any other entity suspects private key compromise, they should notify the issuing CA.

9.6.4 Relying party representations and warranties TeliaSonera and all CAs residing under the TeliaSonera Public Root Service will require that Relying Parties comply with all the relevant provisions of this CPS.



Prior to using a Subscriber's certificate, a Relying Party is responsible for verifying that the certificate is appropriate for the intended use. A Relying Party should use certificates only in accordance with the certification path validation procedure specified in X.509 and PKIX. Prior to using a certificate, a Relying Party is responsible for checking 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. TeliaSonera will provide certificate status information identifying the access point to the CRL or on-line certificate status server in every certificate TeliaSonera issues in accordance with section 4.9.6 and 4.9.9.

9.6.5 Representations and warranties of other participants No Stipulation.

9.7 Disclaimers of warranties The RSA Root Signing Service assumes no liability except as stated in the relevant contracts pertaining to certificate issuance and management, such as the Root Signing Agreement, a Subscriber Agreement or other relevant customer contract. TeliaSonera assumes no liability except as stated in the relevant contracts pertaining to certificate issuance and management, such as the Root Signing Agreement, a Subscriber Agreement or other relevant customer contract.

9.8 Limitations of liability The RSA Root Signing Service assumes no liability except as stated in the relevant contracts pertaining to certificate issuance and management, such as the Root Signing Agreement, a Subscriber Agreement or other relevant customer contract. TeliaSonera assumes no liability except as stated in the relevant contracts pertaining to certificate issuance and management, such as the Root Signing Agreement, a Subscriber Agreement or other relevant customer contract.

9.9 Indemnities As agreed in the relevant Subscriber Agreement and/or Relying Party Agreement. The relevant Subscriber Agreements and Relying Party Agreements will be defined in the CPS’s of the different services and customer CAs residing under the TeliaSonera Public Root Service.

9.10 Term and termination

9.10.1 Term This CPS remains in force until notice of the opposite is communicated by TeliaSonera on its web site in the TeliaSonera eID Service Repository (https://repository.trust.telia.com).

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 TeliaSonera’s web site in the TeliaSonera eID Service Repository (https://repository.trust.telia.com), upon termination outlining the provisions that may survive termination of the document and remain in force.

9.11 Individual notices and communications with participants TeliaSonera will define in any applicable agreement the appropriate provisions governing notices.



9.12 Amendments TeliaSonera CPS Management Team (CPSMT) is the responsible authority for reviewing and approving changes to this CPS. Written and signed comments on proposed changes shall be directed to the TeliaSonera Public Root Service contact as described in Section 1.5. Decisions with respect to the proposed changes are at the sole discretion of the TeliaSonera CPS Management Team.

9.12.1 Procedure for amendment CPS publication will be done in accordance with Section 2. An electronic copy of TeliaSonera Production CPS is to be made available at the TeliaSonera eID Services web site https://repository.trust.telia.com, or by requesting an electronic copy by e-mail to the contact representative as described in Section 1.5. The TeliaSonera CPS Management Team may provide notice, in writing, of any proposed changes to this CPS, if in the judgment and discretion of TeliaSonera CPS Management Team the changes may have significant impact on the issued certificates, or PKI services. The period of time that affected parties have to conform to the change will be defined in the notification.

9.12.2 Notification mechanism and period Changes which can take place without notification: The only changes which can be carried out to this CPS without notification are linguistic amendments and rearrangements which do not affect the security level of the described procedures and regulations. Changes which shall take place with notification:

a) All types of changes can be made to this CPS 90 days after notification. b) Minor changes of lesser importance and which affect only a small number of key holders or

trusting parties may be made 30 days after notification. The notification shall contain a statement of proposed changes, the final date for receipt of comments, and the proposed effective date of the changes. The TeliaSonera CPS Management Team will post the notification at the CPS publishing point at (https://repository.trust.telia.com). In term of changes in accordance with a) comments should be received no later than 45 days after publication of notification. In term of changes in accordance with b) comments should be received no later than 15 days after publication of notification. TeliaSonera CPS Management Team 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 30 days after publication of a new modified notification. All changes to this CPS shall be consistent with the certificate policy or policies identified in section 1.2.

9.12.3 Circumstances under which OID must be changed If a CPS change is determined by the TeliaSonera CPS Management Team to warrant the issuance of a new CPS, the TeliaSonera CPS Management Team will assign a new Object Identifier (OID) for the new CPS.

9.13 Dispute resolution provisions If a dispute relating to this CPS is not successfully resolved by negotiations, it shall be settled by arbitration in accordance with the Reconciliation and Arbitration Rules of the International Chamber of Commerce (ICC). The Stockholm Chamber of Commerce shall administer the reconciliation in accordance with the ICC’s rules, and the venue for arbitration shall be Stockholm. The proceedings shall be held in Swedish unless the parties agree to hold them in English.

9.14 Governing law Swedish law shall apply to the interpretation of this CPS, if not otherwise agreed, and in assessing TeliaSonera’s actions in relation to the certificate issuing services in accordance with this CPS



9.15 Compliance with applicable law TeliaSonera and all CAs residing under the TeliaSonera Public Root Service will, in relation to the RSA Root Signing Service, comply with applicable national, state, local and foreign laws, rules, regulations, ordinances, decrees and orders including but not limited to restrictions on exporting or importing software, hardware or technical information.

9.16 Miscellaneous provisions

9.16.1 Entire agreement The RSA Root Signing Service Agreement signed between RSA and TeliaSonera will define the appropriate provisions governing severability and survival of clauses, assignment of the agreement and notice requirements.

9.16.2 Assignment The RSA Root Signing Service Agreement signed between RSA and TeliaSonera will define the appropriate provisions governing assignment. Subscribers and Relying Parties may not assign any of their rights or obligations under their applicable agreements, without the written consent of TeliaSonera Public Root Service.

9.16.3 Severability The RSA Root Signing Service Agreement signed between RSA and TeliaSonera will define the appropriate provisions governing severability.

9.16.4 Enforcement (attorneys’ fees and waiver of rights) The RSA Root Signing Service Agreement signed between RSA and TeliaSonera will define the appropriate provisions governing enforcement.

9.16.5 Force Majeure TeliaSonera 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, or other similar causes beyond its reasonable control and without the fault or negligence of TeliaSonera or its subcontractors.

9.17 Other provisions No stipulation.



Acronyms and Definitions Acronyms CA Certification Authority CP Certificate Policy CPS Certification Practice Statement CRL Certificate Revocation List DER Distinguished Encoding Rules DN Distinguished Name DSA Digital Signature Algorithm EAL Evaluation Assurance Level EID Electronic Identification FIPS Federal Information Processing Standard HSM Hardware Security Module IETF Internet Engineering Task Force ISO International Organization for Standardization LDAP Lightweight Directory Access Protocol MD5 Message Digest 5 OCSP On-line Certificate Status Protocol OID Object Identifier PIN Personal Identification Number PKCS Public Key Cryptography Standards PKI Public Key Infrastructure PKIX Public Key Infrastructure X.509 (IETF Working Group) RA Registration Authority RFC Request For Comments RSA Rivest-Shamir-Adleman asymmetric encryption algorithm SEIS Secure Electronic Information in Society SHA –1 Secure Hash Algorithm S/MIME Secure Multipurpose Internet Mail Extension SSL Secure Sockets Layer TTP Trusted Third Party UPS Uninterruptible Power Supply URI Uniform Resource Identifier URL Uniform Resource Locator



Definitions Access control: The granting or denial of use or entry. Activation Data: Activation data, in the context of certificate enrollment, consists of a one-time secret communicated to the enrolling user (Subscriber) out of band. This shared secret permits the user to complete of the enrollment process. Administrator: A Trusted Person within the organization of a Processing Center, Service Center, Managed PKI Customer, or Gateway Customer that performs validation and other CA or RA functions. Administrator Certificate: A Certificate issued to an Administrator that may only be used to perform CA or RA functions. Agent: A person, contractor, service provider, etc. that is providing a service to an organization under contract and are subject to the same corporate policies as if they were an employee of the organization. Application Server: An application service that is provided to an organizational or one of its partners and may own a certificate issued under the organizational PKI. Examples are Web SSL servers, VPN servers (IPSec), object signer services, Domain Controllers, etc. Authentication: Checking the identity provided, e.g. when logging in, in the event of communication between two systems or when exchanging messages between users. General: strengthening of authenticity. Authorization: The granting of permissions of use. Authorised representative: An employee of the commissioner who has the authority to order and revoke certificates at the CA. Asymmetric encryption algorithm: An encryption technique which uses two related transformation algorithms: a public transformation, with the use of a public key, and a private transformation with the use of a private key. The two transformations are such that if the public transformation is known, it is mathematically impossible to derive the private transformation from this. Base certificate: See primary certificate. Business process: A set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships. CA certificate: Certificate which certifies that a particular public key is the public key for a specific CA. CA key: Key pair where the private key is used by the CA in order to sign certificates and where the public key is used to verify the same certificate.



Certificate: The public key of a user, together with related information, digitally signed with the private key of the Certification Authority that issued it. The certificate format is in accordance with ITU-T Recommendation X.509. Certificate extensions: Sections of certificate content defined by standard X.509 version 3. Certificate level: Certificates exist at two levels: primary certificates and secondary certificates. Certification Authority (CA): An authority trusted by one or more users to manage X.509 certificates and CRLs. Certification Chain: An ordered list of Certificates containing an end-user Subscriber Certificate and CA Certificates, which terminates in a root Certificate. Certificate Policy: Named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements. It is the principal statement of certificate policy governing the organizational PKI. The CP is a high-level document that describes the requirements, terms and conditions, and policy for issuing, utilizing and managing certificates issued by a CA. Certification Practice Statement (CPS): A statement of the practices, which a Certification Authority employs in issuing certificates. It is a comprehensive description of such details as the precise implementation of service offerings and detailed procedures of certificate life-cycle management and will be more detailed than the certificate policies supported by the CA. Certificate Revocation List (CRL): A periodically issued list, digitally signed by a CA, of identified Certificates that have been revoked prior to their expiration dates. The list generally indicates the CRL issuer’s name, the date of issue, the date of the next scheduled CRL issue, the revoked Certificates’ serial numbers, and the specific times and reasons for revocation. CRL can be used to check the status of certificates. Confidential: A security classification used to describe information which if disclosed could result in personal loss or minor financial loss. Personal information and tactical information would be deemed confidential. Confidentiality: Information that has an identifiable value associated with it such that if disclosed might cause damage to an entity. Cross Certification: The process describing the establishing of trust between two or more CAs. Usually involves the exchange and signing of CA certificates and involves the verification of assurance levels. Cryptographic Module: A unit in which encryption keys are stored together with a processor which can carry out critical cryptographic algorithms. Examples of cryptographic modules include EID cards. Decryption: The process of changing encrypted (coded) information into decrypted (legible) information. See also encryption. Distinguished Encoding Rules (DER): The Distinguished Encoding Rules for ASN.1, abbreviated DER, gives exactly one way to represent any ASN.1 value as an octet string. DER is intended for applications in which a unique octet string encoding is needed, as is the case when a digital signature is computed on an ASN.1 value.



Digital Signature: The result of the transformation of a message by means of a cryptographic system using keys such that a person who has the initial message can determine that the key that corresponds to the signer’s key created the transformation and the message was not altered. Directory Service: Database service which in this document relates to a database structure in accordance with standard X.500 or LDAP. Distinguished Name (DN): Every entry in a X.500 or LDAP directory has a Distinguished Name, or DN. It is a unique entry identifier through out the complete directory. No two Entries can have the same DN within the same directory. A DN is used in certificates to uniquely identify a certificate-owner. Dual Control: A process utilizing two or more separate entities (usually persons), operating in concert, to protect sensitive functions or information, whereby no single entity is able to access or utilize the materials, e.g., cryptographic key. EID card: Electronic ID card in the form of an active card containing certificates and keys while the front of the card can be used as a visual ID document. Electronic identity check: Identity check which can be carried out without the persons whose identity is being checked being present in person. Electronic signature: General signature designation created using IT. Digital equivalent to traditional signature. See also digital signature. Encryption: The process of changing information which can be interpreted (clear text) into encrypted information. The aim of the encrypted information is that it shall not be interpretable by anyone who does not hold exactly the right key (in symmetrical encryption) or exactly the right private key (in asymmetrical encryption) required to correctly decrypting the information. E-mail Certificates: Certificates utilized for encrypting and verifying digital signatures. Normally two separate certificate: one for encryption, the other for signature verification. Entity: Any autonomous element or component within the Public Key Infrastructure that participate is one form or another, such managing certificates or utilizing certificates. An Entity can be a CA, RA, Subscriber, Relying Party, etc. FIPS 140-2: Federal Information Processing Standard 140-2(FIPS 140-2) is a standard that describes US Federal government requirements that IT products shall meet for Sensitive, but Unclassified (SBU) use. The standard was published by the National Institute of Standards and Technology (NIST), has been adopted by the Canadian government's Communication Security Establishment (CSE), and is likely to be adopted by the financial community through the American National Standards Institute (ANSI). The different levels (1 to 4) within the standard provide different levels of security and in the higher levels, have different documentation requirements. FIPS 180-1: Standard specifying a Secure Hash Algorithm, SHA-1, for computing a condensed representation of a message or a data files.



Integrity: Ensuring consistency of an object or information. Within security systems, integrity is the principle of ensuring that a piece of data has not been modified maliciously or accidentally. ISO 11568-5: Basic principles and requirements for Key lifecycle for public key cryptosystems, provides instructions to financial institutions in the development, implementation and/or the operation of systems and procedures throughout Key’s lifecycle Key: When used in the context of cryptography, it is a secret value, a sequence of characters that is used to encrypt and decrypt data. A key is a unique, generated electronic string of bits used for encrypting, decrypting, e-signing or validating digital signatures. Key holder: In this context, a person, an organization, an organizational unit or a function which has exclusive control of the private key, the public equivalent of which is certified in a certificate. See also subscriber. Key Pair: Often referred to as public/private key pair. One key is used for encrypting and the other key used for decrypting. Although related, the keys are sufficiently different that knowing one does not allow derivation or computation of the other. This means that one key can be made publicly available without reducing security, provided the other key remains private. Log: A sequential and unbroken list of events in a system or a process. A typical log contains log entries for individual events, each containing information on the event, who initiated it, when it occurred, what it resulted in, etc. MD5: A Message Digest Algorithm. Non-repudiation: Protection against the denial of the transaction or service or activity occurrence. Non-repudiation services: Service which aim to hold a key holder responsible for signed messages in such a way that they can be verified by a third party at a later point in time. Object Identifier: The unique alpha-numeric identifier registered under the ISO registration standard to reference a standard object or class. Operator: Employee of a CA. PKCS #1: Standard that provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering the following aspects: cryptographic primitives; encryption schemes; signature schemes, etc. PKCS #7: A cryptographic message format or syntax managed and edited by RSA Laboratories. A standard describing general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. PKCS #10: A certificate request format or syntax managed and edited by RSA Laboratories. It is a standard describing syntax for a request for certification of a public key, a name, and possibly a set of attributes.



PKIX: The Public Key Infrastructure (X.509) or PKIX is an IETF Working Group established with the intent of developing Internet standards needed to support an X.509-based PKI. The scope of PKIX extends to also develop new standards for use of X.509-based PKIs in the Internet. PKI personnel: Persons, generally employees, associated with the operation, administration and management of a CA or RA. Policy: The set of laws, rules and practices that regulates how an organization manages its business. Specifically, security policy would be the set of laws, rules and practices that regulates how an organization manages, protects and distributes sensitive information. Primary certificate: A certificate which is issued on the basis of identifying key holders other than by the key holder producing another certificate. Identification then normally takes place through the key holder instead producing an identity document. PrintableString: String format for representing names, such as Common Name (CN), in X.509 certificates. The encoding of a value in this syntax is the string value itself. Private Key: The private key is one of the keys in a public/private key pair. This is the key that is kept secret as opposed to the other key that is publicly available. Private keys a utilized for digitally signing documents, uniquely authenticating an individual, or decrypting data that was encrypted with the corresponding public key. Public Key Infrastructure: A set of policies, procedures, technology, audit and control mechanisms used for the purpose of managing certificates and keys. Public: A security classification for information that if disclosed would not result in any personal damage or financial loss. Public Key: The community verification key for digital signature and the community encryption key for encrypting information to a specific Subscriber. RA policy: A named set of rules for the RA’s role in producing, issuing and revoking certificates and which regulates the applicability of certificates within a specific area of application. Registration Authority (RA): An entity that performs registration services on behalf of a CA. RAs work with a particular CA to vet requests for certificates that will then be issued by the CA. Re-key: The process of replacing or updating the key(s). The expiration of the crypto period involves the replacement of the public key in the certificate and therefore the generation of a new certificate. Relative Distinguished Name (RDN): A Distinguished Name is made up of a sequence of Relative Distinguished Names, or RDNs. The sequences of RDNs are separated by commas (,) or semi-colons (;). There can be more than one identical RDN in a directory, but they must be in different bases, or branches, of the directory.



Relying Party: A person or entity that uses a certificate signed by the CA to authenticate a digital signature or encrypt communications to a certificate subject. The relying party relies on the certificate as a result of the certificate being sign by a CA, which is trusted. A relying party normally is but does not have to be a Subscriber of the PKI. Repository: A place or container where objects are stored. A data repository is technology where data is stored logically. In PKI terms, a repository accepts certificates and CRLs form one or more CAs and makes them available to entities that need them for implementing security services. Revocation: In PKI, revocation is the action associated with revoking a certificate. Revoking a certificate is to make the certificate invalid before its normal expiration. The Certification Authority that issued the certificate is the entity that revokes a certificate. The revoked status is normally published on a certificate revocation list (CRL). RSA: A public key cryptographic algorithm invented by Rivest, Shamir, and Adelman. Secondary certificate: A certificate issued on the basis of another certificate, the primary certificate. This means that the issuing CA relies on the CA which issued the primary certificate, i.e. accepts the public key’s certification of the key holder, which is turn requires reliance on the identification of the key holder when issuing the primary certificate being correct. Sensitive: Used to describe the security classification of information where the information if disclosed would result in serious financial loss, serious loss in confidence or could result in personal harm or death. Signature Verification Certificate: Often referred to as simply a Signature Certificate. It is the certificate containing the public key used to verify a digital signature that was signed by the corresponding private key. Split Knowledge A condition under which two or more parties separately and confidentially have custody of components of a single key that, individually, convey no knowledge of the resultant cryptographic key. The resultant key exists only within secure cryptographic devices. SSL Client Certificate: Certificate utilized to verify the authentication of an end user to a server when a connection is being established via a SSL session (secure channel). SSL Server Certificate: Certificate utilized to verify the authentication of a web or application server to the end user (client) when a connection is being established via a SSL session (secure channel). Storage module: In this document relates to cryptographic module. Subscriber: A Subscriber is an entity; a person or application server that is a holder of a private key corresponding to a public, and has been issued a certificate. In the case of a application server, a person authorized by the organization owning the application server may be referred to as the Subscriber. A Subscriber is capable of using, and is authorized to use, the private key that corresponds to the public key listed in the certificate.



Surveillance Camera: A surveillance camera is a video recording device used for detection and identification of unauthorized physical entry to a secured area. A camera used for recording a signing ceremony for auditing purposes is not considered a surveillance camera. Symmetric encryption: Encryption system characterised by both the sender and the recipient of encrypted information using the same secret key for both encryption and decryption. Threat: A danger to an asset in terms of that asset's confidentiality, integrity, availability or legitimate use. Token: Hardware devices, normally associated with a reader, used to store and/or generate encryption keys, such as smartcards and USB tokens. Trusted Third Party (TTP): A party on which two or more collaborative parties rely. A TTP carries out services for the collaborative parties, such as time-stamping, certificate issuing, etc. Trusting party: A recipient of a certificate which trusts this certificate on authentication, verification of digital signatures and/or encryption of information. See also Relying Party. Unambiguous identity: An identity comprising a set of attributes which relate unambiguously to a specific person. The unambiguous connection between the identity and the person may be dependant on the context within which the identity term is used. Certain contexts may require assistance from the current registrar of various attributes. URI Universal Resource Indicator - an address on the Internet. UTF8String UTF-8 is a type of Unicode, which is a character set supported across many commonly used software applications and operating systems. UTF-8 is a multibyte encoding in which each character can be encoded in as little as one byte and as many as four bytes. Most Western European languages require less than two bytes per character. Greek, Arabic, Hebrew, and Russian require an average of 1.7 bytes. Japanese, Korean, and Chinese typically require three bytes per character. Such Unicode is important to ensure universal character / foreign characters are supported. Verification: The process of ensuring that an assumption is correct. This term relates primarily to the process of ensuring that a digital signature represents the party which the signed information details as its issuer. Vettor: A person who verifies information provided by a person applying for a certificate. Vulnerability: Weaknesses in a safeguard or the absence of a safeguard. Written: Where this CPS specifies that information shall be written, this requirement is generally also met by digital data provided that the information it contains is accessible in such a way that it is useable by the parties involved. X.500 Specification of the directory service required to support X.400 e-mail initially but common used by other applications as well.



X501 PrintableString: String format for representing names, such as Common Name (CN), in X.509 certificates. The encoding of a value in this syntax is the string value itself; an arbitrary string of printable characters. X.509: An ISO standard that describes the basic format for digital certificates.

Documents

TeliaSonera Public Root CA Certification Practice Statement Public... · Document no 1/011 01-AZDA 102 213 TeliaSonera Sverige AB – Certification Practice Statement – Rev A TeliaSonera