TeliaSonera Gateway Certificate Policy and Certification Practice Statement

Transcription

1 TeliaSonera Gateway Certificate Policy and Certification Practice Statement v. 1.2 TeliaSonera Gateway Certificate Policy and Certification Practice Statement TeliaSonera Gateway CA v1 OID Revision Date: 3 rd April 2014 Version: 1.2 Published by: TeliaSonera

2 Copyright TeliaSonera 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. 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. Page II

3 Table of Contents Table of Contents...III Revision History... VII 1 INTRODUCTION Overview Document name and identification PKI participants Certification authorities Registration authorities Subscribers Relying parties Other participants Certificate usage Appropriate certificate uses Prohibited certificate uses Policy administration Organization administering the document Contact person Person determining CPS suitability for the policy CPS approval procedures Definitions and acronyms PUBLICATION AND REPOSITORY RESPONSIBILITIES Repositories CPS Repository Revocation Information Repository Certificate Repository Publication of certification information Time or frequency of publication Access controls on repositories IDENTIFICATION AND AUTHENTICATION Naming Types of names Need for names to be meaningful Anonymity or pseudonymity of subscribers Rules for interpreting various name forms Uniqueness of names Recognition, authentication, and role of trademarks Initial identity validation Method to prove possession of private key Authentication of organization identity Authentication of individual identity Non-verified subscriber information Validation of authority Criteria for interoperation Identification and authentication for re-key requests Identification and authentication for routine re-key Identification and authentication for re-key after revocation Identification and authentication for revocation request CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS Certificate Application Who can submit a certificate application Enrollment process and responsibilities Certificate application processing Performing identification and authentication functions Approval or rejection of certificate applications Page 3

4 4.2.3 Time to process certificate applications Certificate issuance CA actions during certificate issuance Notification to subscriber by the CA of issuance of certificate Certificate acceptance Conduct constituting certificate acceptance Publication of the certificate by the CA Notification of certificate issuance by the CA to other entities Key pair and certificate usage Subscriber private key and certificate usage Relying party public key and certificate usage Certificate renewal Certificate re-key Certificate modification Certificate revocation and suspension Circumstances for revocation Who can request revocation Procedure for revocation request Revocation request grace period Time within which CA must process the revocation request Revocation checking requirement for relying parties CRL issuance frequency Maximum latency for CRL s On-line revocation/status checking availability On-line revocation checking requirements Other forms of revocation advertisements available Special requirements regarding key compromise Circumstances for suspension Who can request suspension Procedure for suspension request Limits on suspension period Certificate status services Operational characteristics Service availability Optional features End of subscription Key escrow and recovery Key escrow and recovery policy and practices Session key encapsulation and recovery policy and practices FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS TECHNICAL SECURITY CONTROLS Key pair generation and installation Key pair generation Private key delivery to subscriber Public key delivery to certificate issuer CA public key delivery to relying parties Key sizes Public key parameters generation and quality checking Key usage purposes (as per X.509 v3 key usage field) Private key protection and cryptographic module engineering controls Cryptographic module standards and controls Private key (n out of m) multi-person control Private key escrow Private key backup Private key archival Private key transfer into or from a cryptographic module Private key storage on cryptographic module Method of activating private key Method of deactivating private key Page 4

5 Method of destroying private key Cryptographic module rating Other aspects of key pair management Public key archival Certificate operational periods and key pair usage periods Activation data Activation data generation and installation Activation data protection Other aspects of activation data CERTIFICATE, CRL, AND OCSP PROFILES Certificate profile Version number(s) Certificate extensions Algorithm object identifiers Name forms Name constraints Certificate policy object identifier Usage of Policy Constraints extension Policy qualifiers syntax and semantics Processing semantics for the critical Certificate Policies extension CRL profile Version number(s) CRL and CRL entry extensions OCSP profile Version number(s) OCSP extensions COMPLIANCE AUDIT AND OTHER ASSESSMENTS Frequency or circumstances of assessment Identity/qualifications of assessor Assessor's relationship to assessed entity Topics covered by assessment Actions taken as a result of deficiency Communication of results OTHER BUSINESS AND LEGAL MATTERS Fees Certificate issuance or renewal fees Certificate access fees Revocation or status information access fees Fees for other services Refund policy Financial responsibility Confidentiality of business information Privacy of personal information Intellectual property rights Representations and warranties Disclaimers of warranties Limitations of liability Indemnities Term and termination Term Termination Effect of termination and survival Individual notices and communications with participants Amendments Procedure for amendment Notification mechanism and period Circumstances under which OID must be changed Dispute resolution provisions...31 Page 5

6 9.14 Governing law Compliance with applicable law Miscellaneous provisions Other provisions...31 ACRONYMS...32 DEFINITIONS...33 Page 6

7 Revision History Version Version date Change Author th June 2012 The first official version TeliaSonera CA Policy Management Team th September 2012 Fixed minor errors in references TeliaSonera CA Policy Management Team st December 2012 Added OCSP support, Small clarifications to used TeliaSonera CA Policy Management Team processes and text, Distinction of client and server certificates, Fixed AIA and EKU extension description, Fixed ST,L,C attribute description, Mandatory 2048 bit RSA key length 1.1 3rd May 2013 Geographical definition to Server Certificates, Suspension no more used, small technical fixes TeliaSonera CA Policy Management team 1.2 3rd April 2014 All Subject fields except O and OU will refer to registered O location. Small fixes and clarifications TeliaSonera CA Policy Management team Page VII

8 1 INTRODUCTION 1.1 Overview A Certification Practice Statement (CPS) is a Certification Authority s (CA) description of the practices it follows when issuing certificates. The purpose of this CPS is to describe the procedures that the TeliaSonera Gateway CA v1 uses when issuing certificates, and that all Registration Authorities, Subscribers and Relying Parties shall follow in connection with these certificates. This CPS describes the procedures and routines which apply when registering and completing a certificate and for revoking and revocation checking of certificates. This CPS will refer to separate TeliaSonera Production CPS, which describes the premises, procedures and routines which apply for the Production of TeliaSonera CA Services. This 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. This CPS and all certificates containing the OID value reserved for this CPS conform to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document. 1.2 Document name and identification This CPS is titled TeliaSonera Gateway Certificate CPS and the CPS name of this CPS is {TELIASONERA-GATEWAY-CPS-1}. This CPS is also a Certificate Policy for TeliaSonera gateway certificates. The routines and roles resulting from this CPS apply only in connection with certificates referring to the following Certificate policy object identifier: This CPS also refers to the TeliaSonera Production CPS with the name {TELIASONERA- PRODUCTION-CPS-2}. 1.3 PKI participants TeliaSonera gateway certificates are issued to devices (e.g. VPN gateways and clients) required by the services provided by TeliaSonera to its customer organizations or to its internal use. Page 8

9 1.3.1 Certification authorities The Certification Authority operating in compliance with this Certification Practice Statement is TeliaSonera. The name of the Certification Authority in the Issuer field of the certificate is TeliaSonera Gateway CA v1. TeliaSonera Gateway CA v1 is a subordinate CA of TeliaSonera Root CA v1. TeliaSonera Root CA has its own CPS describing the management of the certificate life cycle of subordinate CA certificates signed by it. The title of that CPS is TeliaSonera Root CPS and its CPS name is {TELIASONERA- ROOT-CPS-2}. The Certification Authorities are responsible for managing the certificate life cycle of end entity certificates signed by the CAs. This will include: creating and signing of certificates binding Subjects with their public key promulgating certificate status through CRLs Registration authorities The CA s units and systems authorized to perform registration functions act as Registration Authorities. RA is responsible for the following activities on behalf of a CA: identification and authentication of certificate subscribers approve applications for renewal or re-keying certificates initiate or pass along revocation requests for certificates Subscribers The Subscriber is an entity subscribing with a Certification Authority on behalf of one or more device (Subject). The Subscriber for the gateway certificates is an employee of TeliaSonera, who requests gateway certificate from the RA. The Subscriber shall ensure that the Subject and the certificate information fulfill the obligations defined in this CPS and the conditions of the certification services. The Subject of a certificate is a Device with installed software capable of utilizing the private key stored in the Device Relying parties The Relying Party is a Customer Organization, which utilizes certificates for securing the organization s internal or external activities. The Relying Party can also be a company, organization or a private person having business with the Customer Organization. In case of TeliaSonera s internal certificates, the relying party is TeliaSonera Other participants No stipulation. 1.4 Certificate usage Appropriate certificate uses Certificates under this CPS are issued to servers or devices to be used for the following applications: - VPN gateway certificate is a server certificate issued to VPN gateway devices possessed by TeliaSonera. VPN gateway certificate is used to authenticate VPN gateway devices and to create VPN OR SSL VPN connections. - VPN tunnel certificate is a technical client certificate used by VPN clients to create IPSec VPN tunnel with the VPN gateway. All the VPN clients connecting to the same VPN gateway use the same certificate and key pair. Actual authentication of the remote user is made by other means (e.g. using other TeliaSonera certificates). - TeliaSonera s internal device certificates are issued to servers managed by TeliaSonera and other devices required by TeliaSonera s internal services (e.g LDAP servers) Page 9

10 1.4.2 Prohibited certificate uses Applications using certificates issued under this CPS shall take into account the key usage purpose stated in the Key Usage extension field of the certificate. Additionally, the key usage purposes and limitations possibly stated in the contract between the Customer Organization and the CA shall be taken into account when using certificates. 1.5 Policy administration Organization administering the document TeliaSonera CA Policy Management Team 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 contact as described in Section Decisions with respect to the proposed changes are at the sole discretion of the TeliaSonera CA Policy Management Team. Contact information: TELIASONERA AB SE Stockholm Phone: +46 (0) Internet: Contact person Contact person in matters related to this CPS: TeliaSonera CA Product Manager Phone: +358 (0) Internet: Person determining CPS suitability for the policy TeliaSonera CA Policy Management Team is the administrative entity for determining this Certification Practice Statement (CPS) suitability to the applicable policies CPS approval procedures TeliaSonera CA Policy Management Team will review any modifications, additions or deletions from this CPS and determine if modifications, additions or deletions are acceptable and do not jeopardize operations or the security of the production environment. 1.6 Definitions and acronyms A list of definitions and acronyms can be found at the end of this document. Page 10

11 2 PUBLICATION AND REPOSITORY RESPONSIBILITIES 2.1 Repositories CPS Repository A full text version of this CPS is published at Revocation Information Repository OCSP is the recommended Revocation Information Repository. It can be found from Certificate Revocation Lists (CRLs) are published in the TeliaSonera LDAP directory and on the TeliaSonera website: Issuing CA TeliaSonera Gateway CA v1 CRL addresses ldap://crl-1.trust.teliasonera.com/cn=teliasonera%20gateway%20ca %20v1,o=TeliaSonera?certificaterevocationlist;binary If OCSP is not used then http based CRL repository is recommended. It is listed at first on certificate s CDP extension Certificate Repository All issued certificates are stored in the local database of the CA system. Certificates may also be published to other repositories if it is a part of the TeliaSonera CA Service or agreed with a customer. 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 c) Issued CA certificates and cross certificates for cross-certified CAs TeliaSonera may publish and supply certificate information in accordance with applicable legislation. Each published certificate revocation list (CRL) provides all processed revocation information at the time of publication for all revoked certificates of which the revocation list is intended to give notification. 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 Time or frequency of publication Updates to this CPS are published in accordance with the provisions specified in section Revocation information publication provisions are specified in section 4.9. All issued certificates are stored in the local database of the CA system promptly on issuing. Certificates may also be published to other repositories if it is a part of the TeliaSonera CA Service or agreed with a customer. 2.4 Access controls on repositories This CPS, CRLs and CA certificates are publicly available. Only authorized CA personnel have access Page 11

12 to subscriber certificates stored in the local database of the CA system. Page 12

13 3 IDENTIFICATION AND AUTHENTICATION 3.1 Naming Types of names An X.501 Distinguished Name (DN) is used as an unambiguous name of the Subject in the Subject field of the certificate. The name always includes the following attributes: Attribute commonname (CN, OID ) Organization (O, OID ) Description of value commonname is a character string defined by TeliaSonera describing a device that is used to provide services of TeliaSonera. Typically the commonname attribute is a hostname, domain name or IP address of the certificate Subject. Organization is a character string defined by TeliaSonera. Typically the Organization attribute is the name of the TeliaSonera s customer organization using the service related to the Subject. Additionally, the Subject field may include following attributes depending on the usage purpose of the certificate: Attribute organizationalunit (OU, OID ) State of province (ST, OID ) Locality (L, OID ) Country (C, OID ) Description of value Character string defined by TeliaSonera, which can be used to indicate the service of TeliaSonera, with which the certificate is used. Qualifier for describing the location of the customer using the service related to the Subject. Qualifier for describing the location of the customer using the service related to the Subject. Qualifier for describing the location of the customer using the service related to the Subject.. Subject name information may also be contained in the Subject Alternative Name X.509 version 3 extension. Subject Alternative Name extension may contain following attributes: SAN Attribute dnsname ipaddress Description of value One or more DNS domain names (FQDN) of the Subject. May also contain wildcard domain names (e.g. *.teliasonera.com ). Internal server names are not used in certificates created after September No certificates with internal server names will be valid after October 1, Internal server name is a server name without a domain name or with Unregistered Domain Name. CA verifies that the domain part of a FQDN can be found from a public domain register. One or more IP addresses of the Subject. Reserved IP addresses are not used in certificates created after September No certificates with reserved IP addresses will be valid after October 1, Reserved IP address is an IPv4 or IPv6 address that the IANA has marked as reserved. Additional Distinguished Name (DN) or Subject Alternative Name attributes may be used as necessary. Page 13

14 3.1.2 Need for names to be meaningful Names will be meaningful as stated in the section Anonymity or pseudonymity of subscribers No stipulation Rules for interpreting various name forms No stipulation Uniqueness of names The Subject name stated in a certificate will be unique for all certificates issued within the domain of the CA, and conform to X.500 standards for name uniqueness. Subject name uniqueness means that the CA will not issue certificates with identical names to different organizations. However, the CA may issue several certificates to the same organization, and in that case the Subject names in those certificates may be the same Recognition, authentication, and role of trademarks The priority to entity names is given to registered trademark holders. The use of a Domain Name or IP address is restricted to the authenticated legal owner of that Name. TeliaSonera reserves the right not to issue such a certificate, or to revoke a certificate that has already been issued, when there is a name claim dispute involved concerning the certificate contents. 3.2 Initial identity validation Method to prove possession of private key Key pairs are created by TeliaSonera. The CA verifies that the certificate orderer possesses the private key by verifying the electronic signature included in the PKCS #10 certificate request. The request is accepted only when signed with the private key associated with the public key to be certified Authentication of organization identity The existence of the company, its legal name, business identity code and other relevant organization information are confirmed from an official business register maintained by an applicable government agency (e.g. ytj.fi in Finland) or from certified true copy of the organization s incorporation papers. TeliaSonera verifies domain names and IP addresses from a database maintained by a reliable third party registrar e.g. domain.fi (for domain.fi ), iis.se (for domain.se ), ripe.net (for IP addresses) and (for non-country domains), that as of the date the Certificate was issued, the Customer either had the right to use, or had control of, the Fully-Qualified Domain Name(s) and IP address(es) listed in the Certificate, or was authorized by a person having such right or control (e.g. under a Principal-Agent or Licensor-Licensee relationship) to obtain a Certificate containing the Fully-Qualified Domain Name(s) and IP address(es). Connection to the third party database is SSL/TLS protected when applicable. OrganizationalUnit may be used to indicate the service of TeliaSonera, with which the certificate is used. If the Subject Identity Information is to include a Customer DBA, the CA verifies the Applicant s right to use the DBA from applicable government agency responsible of such names (e.g. ytj.fi in Finland). In FullSSL service such verification to done by the Registration Officer. In all cases TeliaSonera CA regularly validates that the all Registration Officers have done the verification of all subject fields correctly. Alternatively the Registration Officer may use another allowed authentication methods listed in the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at Authentication of individual identity Only authorized TeliaSonera employees can apply for gateway certificates used by devices as required by certain TeliaSonera s services. If the employee is an authorized Registration Officer Page 14

15 TeliaSonera Gateway Certificate CPS he/she is authenticated by means of the certificate or other two factor authentication mechanism. Alternatively the employee is using a private order form for gateway certificates. In that case the employee is authenticated by using a special list of authorized TS employees Non-verified subscriber information The Registration Officer is obliged to always review all subject information and initiate additional checking routines if there are any unclear Subject values. Only well-known certificate extensions are verified and others are accepted without verification. Domain name ownership of domains in addresses is not verified by Teliasonera Validation of authority SSL order by electronic form Administrative and technical contact persons are always TeliaSonera employees. Their address domain must be teliasonera.com and at least administrative contact person can be found from TeliaSonera employee register. CA verifies that the Customer has authorized TeliaSonera to create gateway SSL certificates on behalf of the Customer. Authorization may be done when Customer has ordered the service or separately using a special authorization form signed by the Customer representative. SSL enrolment using TeliaSonera s self-service software Self-service software may be used only by authorized TeliaSonera Registration Officers. Authorization is done at application level based on strong authentication. Self-service method may be used for client certificates (Tunnel certificates via GWCerttool) or for TeliaSonera CA s own devices (Gateway certificates via SecureManager) or in special cases when multiple Gateway certificates are needed so that the normal electronic SSL order form would be impractical. In the last case the authorization must come directly from TeliaSonera PKI Security Board and separately from each Customer if customer names are used in the certificates Criteria for interoperation Not applicable. 3.3 Identification and authentication for re-key requests Identification and authentication for routine re-key Re-key requests may be done by authorized TeliaSonera personnel without new validation of the certificate data. However, previous data validation check shouldn t be older than three years. In practice non-validated re-key requests are used when the device holding the original certificate and private key is renewed or re-installed before the expiration of the original certificate. Typically this is done because of device failure Identification and authentication for re-key after revocation As described in Identification and authentication for revocation request Revocation TeliaSonera Registration Officer may revoke gateway certificates as necessary. He/she is authenticated based on certificate or other two factor authentication mechanism. This is a routine operation when renewing certificates The Subscriber or other TeliaSonera employee shall submit a request for certificate revocation to the Revocation Service by telephone or by . The Revocation Service will authenticate requests based on the digital signature or by making a call back to the person requesting revocation and asks certain detailed data. This data is compared with the information recorded about the Subject or Page 15

16 Subscriber at registration. If the data match the certificate will be revoked. In certain situations where there is an identified risk of abuse of the private key or when it is obvious that the authorized use of the key is prevented, the verification of the authenticity of the revocation request can require other authentication methods. In cases where reliable verification cannot be immediately performed the CA may prefer revocation of the certificate, however, to reduce risks. Page 16

17 4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS 4.1 Certificate Application Who can submit a certificate application Authorized employees of TeliaSonera can apply for gateway certificates used by devices as required by certain TeliaSonera s services. TeliaSonera will issue server certificates only to organizations that are registered in the European Economic Area. The European Economic Area (EEA) comprises the countries of the European Union (EU), plus Iceland, Liechtenstein and Norway Enrollment process and responsibilities The authorized employees of TeliaSonera may enroll for a certificate, when the certificate is required for the delivery of TeliaSonera s services. The certificate is enrolled by using an application provided by the CA. Before enrolling the certificate, the Employee is responsible for identifying and authenticating the Subject and validating the authority of the requester if the CA application doesn t validate it automatically. 4.2 Certificate application processing Performing identification and authentication functions TeliaSonera performs identification and authentication of Subject and Subscriber information in accordance with the section Approval or rejection of certificate applications The CA will approve a certificate application if it meets the requirements documented in this CPS and there are no other reasons to reject the application. All other certificate applications will be rejected. The applicant will be informed on why the certificate application was rejected and on how to proceed to be approved Time to process certificate applications The certificate request is processed by CA immediately or within reasonable time frame. 4.3 Certificate issuance CA actions during certificate issuance If the certificate application is approved, the CA issues the certificate. The CA system accepts only such certificate requests the origin of which can be authenticated. The certificate is created by the CA according to the information contained in the certificate request. However, the CA may overwrite or delete some certificate information using pre-defined certificate profile specific standard values Notification to subscriber by the CA of issuance of certificate The certificate is available for the Subscriber in the application after the issuance. 4.4 Certificate acceptance Conduct constituting certificate acceptance The Subscriber is considered to have accepted the certificate when the private key associated with it has been used, or when the certificate has been installed into a Device Publication of the certificate by the CA TeliaSonera will not publish subscriber certificates to a publicly available repository. Page 17

18 4.4.3 Notification of certificate issuance by the CA to other entities No stipulation. 4.5 Key pair and certificate usage Subscriber private key and certificate usage The Subscriber shall only use certificates and their associated key pairs for the purposes identified in this CPS. Issued certificates contain information which defines suitable areas of application for the certificate and its associated keys. Area of application labelling takes place in accordance with X.509 and chapter 7 of this CPS. For more information regarding appropriate subscriber key usage see sections and The subscriber shall protect the Subject private key from unauthorized use and discontinue the use of the Subject private key immediately and permanently in case the private key is compromised Relying party public key and certificate usage Prior to accepting a TeliaSonera gateway certificate, a relying party is responsible to: a) Verify that the certificate is appropriate for the intended use; b) Check the validity of the certificate, i.e. verify the validity dates and the validity of the certificate and issuance signatures; and c) Verify from a valid Certificate Revocation List (CRL) or other certificate status service provided by the CA that the certificate has not been revoked or suspended. If certificate status cannot be verified due to system failure or similar, the certificates shall not be accepted. 4.6 Certificate renewal Certificate renewal is the re-issuance of a certificate with a new validity date using the same public key corresponding to the same private key. When the validity time of a certificate is about to end, the certificate can be renewed. Renewal may be requested by the same persons as the initial certificate application and certificate renewal requests are processed like the initial certificate requests as described in section Certificate re-key Certificate re-key is the re-issuance of a certificate using new public and private keys. Certificate rekey requests are processed as described in section Certificate modification Certificate modification is the re-issuance of the certificate due to changes in the certificate information other than the validity time (certificate renewal) or Subscriber s public key (certificate re-key). Certificate modification requests are processed as initial certificate requests as described in sections Certificate revocation and suspension Circumstances for revocation A certificate must be revoked under the following conditions: 1. Upon suspected or known compromise of the private key; 2. Upon suspected or known compromise of the media holding the private key; 3. Subject or subscriber information is known to be invalid or re-verification fails. 4. When there is an essential error in the certificate Page 18

19 A certificate may be revoked under the following conditions: 1. When any information in the certificate changes; 2. Upon termination of a Subject; 3. When a Subject no longer needs access to secured organizational resources; 4. When the certificate is redundant (for example, a duplicate certificate has been issued). 5. Customer s certificate contract with TeliaSonera has ended. 6. Any other reason that makes the certificate obsolete or threats related keys TeliaSonera in its discretion may revoke a certificate under any circumstances, for example when an entity fails to comply with obligations set out in 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 Who can request revocation The revocation of a certificate can be requested by the Subscriber or other TeliaSonera personnel Procedure for revocation request TeliaSonera Registration Officer can revoke certificates as necessary using tools provided by CA. Other persons requesting revocation may contact TeliaSonera Revocation Service by telephone or . Authorized TeliaSonera revocation staff, then authenticates the identity of the originator of a revocation request according to section 3.4 Identification and authentication for revocation request and processes the revocation request using TeliaSonera s revocation system Revocation request grace period The CA is available for revocation requests 24 hours per day, 7 days per week. When a reason for the revocation of a certificate appears, the Subscriber shall immediately inform the Revocation Service. The CA shall not be responsible for the damage caused by illicit use of the Subject s private key. The CA shall be responsible for the publication of the revocation information on the Certificate Revocation List according to the principles given in this CPS Time within which CA must process the revocation request TeliaSonera processes revocation requests within reasonable time frame. There are no specific requirements for the processing time 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. A certificate cannot be reasonably relied on if the Relying Party does not diligently follow the certificate status checking procedures denoted below: - A Relying Party shall ensure the authenticity and integrity of the CRLs or OCSP responses by checking the digital signature and the certification path related to it. - The Relying Party shall also check the validity period of the CRL or OCSP response in order to make sure that the information is up-to-date. - Certificates may be stored locally in the Relying Party s system, but the prevailing revocation status of each of those certificates shall be checked before use. - If valid certificate status information cannot be obtained because of a system or service failure, not a single certificate must be trusted. The acceptance of a certificate in violation of this condition befalls at the Relying Party's own risk. The Relying Party may acquire the checking of the CRLs as a service that shall follow the certificate status checking procedures denoted above CRL issuance frequency The Revocation Status Service is implemented by publishing Certificate Revocation Lists (CRLs), electronically signed by the CA, in a public directory. The rules below are followed: - A new CRL is published in the directory at intervals of not more than 2 hours. Page 19

20 - The validity time of every CRL is forty-eight (48) hours. There may be several valid CRLs available at the same time. The one of those, which has been published as the latest, contains the most real time information Maximum latency for CRL s CRL s are published to the TeliaSonera LDAP directory and updated automatically. Normally latency will be a matter of seconds On-line revocation/status checking availability TeliaSonera is providing on-line revocation status checking via the OCSP protocol. The OCSP service address is added to certificate extension as defined by RFC 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. 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 section Alternatively the OCSP service may use the original CA database information. In that case the OSCP response has always the latest status information. OCSP responder will not respond with a "good" status for certificates that do not exist in the CA database Other forms of revocation advertisements available No stipulation Special requirements regarding key compromise No stipulation Circumstances for suspension Suspension is not used after March Who can request suspension Suspension is not used after March Procedure for suspension request Suspension is not used after March Limits on suspension period Suspension is not used after March Certificate status services Operational characteristics The primary method for status checking is OCSP Service. The CRLs are published in the TeliaSonera s LDAP directory and website as disclosed in chapter Service availability The certificate status services are available 24 hours per day, 7 days per week Optional features No stipulation End of subscription Page 20

21 TeliaSonera Gateway Certificate CPS The end of a subscription as a result of no longer requiring the service, compromise, or termination of service (voluntary or imposed) may result in the immediate revocation of the certificate and the publishing of a CRL or other certificate status verification system Key escrow and recovery Key escrow and recovery policy and practices A Subscriber s digital signature private keys will not be escrowed Session key encapsulation and recovery policy and practices No stipulation. Page 21

22 5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS All stipulations regarding chapter 5 Facility Management, and Operational Control are specified in TeliaSonera Production CPS. Page 22

23 6 TECHNICAL SECURITY CONTROLS All general stipulations regarding chapter 6 Technical Security Controls are specified in TeliaSonera Production CPS. The sections below are additions to the texts in the corresponding sections of the TeliaSonera Production CPS to complement and specify information concerning Subscriber key management. 6.1 Key pair generation and installation Key pair generation The Subscriber generates the key pair using server or other device software. Third party key generation systems (e.g OpenSSL) can be used if the server itself isn t supporting key generation Private key delivery to subscriber Not applicable Public key delivery to certificate issuer The public key is delivered digitally signed in a Certificate Signing Request (CSR) file CA public key delivery to relying parties Methods to deliver CA certificates to Subscribers and Relying Parties are described in TeliaSonera Production CPS Key sizes The CA requires that the Subscribers generate at least 2048 bit RSA keys Public key parameters generation and quality checking No stipulation Key usage purposes (as per X.509 v3 key usage field) Issued certificates contain information which defines suitable areas of application for the certificate and its associated keys. The CA is not responsible for use other than the given key usage purposes. Area of application labeling takes place in accordance with X.509 and chapter Private key protection and cryptographic module engineering controls Cryptographic module standards and controls The Subscriber private keys are generated by software and normally the private keys are stored in the software of a server, network device or workstation Private key (n out of m) multi-person control No stipulation Private key escrow TeliaSonera does not escrow subscriber private keys Private key backup No backups are made of the subscribers private keys by the CA Private key archival The CA does not archive subscriber private keys. Page 23

24 6.2.6 Private key transfer into or from a cryptographic module Not applicable to subscriber keys Private key storage on cryptographic module Not applicable to subscriber keys Method of activating private key The Subscriber is responsible for the private key activation. The CA recommends that the Subscriber uses passwords or strong authentication methods to authenticate users to the server or other device before the private key is activated in accordance with the section 6.4 and takes other appropriate measures for the logical and physical protection of the server or other device used to store private keys Method of deactivating private key Method of deactivating the private key of the Subscriber depends on the software used by the Subscriber Method of destroying private key When the certificate has expired and has not been renewed, the private key related to it cannot be used any more in connection with certification services. The key is not returned to the CA to be destroyed but it remains in the possession of the Subscriber and should be destroyed by the Subscriber Cryptographic module rating No stipulation. 6.3 Other aspects of key pair management Public key archival The CA stores the Subject public keys according to section 5.5 Records archival in the TeliaSonera Production CPS Certificate operational periods and key pair usage periods The usage period of the subscriber certificate shall not be longer than five (5) years. The same keys may be certified again on expiration of a certificate, although it is not recommended by the CA. The usage period of the Subscriber public and private keys shall not exceed the period during which the applied cryptographic algorithms and their pertinent parameters remain cryptographically strong enough or otherwise suitable. 6.4 Activation data The Subscriber uses his private keys with the help of activation data Activation data generation and installation The Subscriber is responsible for activation data generation and installation. The Subscriber is recommended to use passwords or strong authentication methods to authenticate users to servers or other devices before the private key is activated. If passwords are used, the CA recommends that Subscriber uses passwords that consists of sufficiently many characters and cannot be easily guessed or concluded Activation data protection The Subscriber is recommended to keep his activation data appropriately protected from unauthorized access. Page 24

25 6.4.3 Other aspects of activation data No stipulation. Page 25

26 7 CERTIFICATE, CRL, AND OCSP PROFILES 7.1 Certificate profile The contents definition of a certificate, in other words the certificate profile, defines the fields in a certificate. The certificate profile of the certificates follows the version 3 profile defined in the ITU X.509 standard. The profile of the certificates also follows the document RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. The basic fields used in certificates are listed in the table below: Field name Version Serial number Signature algorithm Issuer Validity Subject Subject public key info Field description and contents This field states which of the certificate versions defined in the X.509 standard the certificate conforms to. The issued certificates conform to the version 3. The CA generates an individual serial number for every certificate. The number that has been given in this field is unique for every certificate created by the CA system. The software manages the uniqueness of the serial number automatically. The signature algorithm is the set of mathematical rules according to which the CA software executes the signing of the certificate. Identifiers have been allocated for the algorithms that are generally used. The identifier of the algorithm used for the signing of the certificate is given in this field. The signature cannot be verified if the algorithm used is not known. The algorithm that is used for the signing of the certificates is sha1rsa or sha256rsa. This field states the name of the Issuer of the certificate. The Issuer name in the certificates of each CA has been described in section The validity of the certificate is that period of time during which the CA guarantees that it maintains status information of the certificate, in other words about the possible revocation of the certificate. This field states the date and time when the certificate comes into force, and the date and time after which the certificate is no more valid. The certificate can be trusted during its validity period if the certificate has not been published on the CRL. This field identifies the Device under whose possession the private key is, that corresponds to the public key contained in the certificate. The field includes the unambiguous name of the Subject. The contents of the field have been described in section 3.1 Naming. This field states the algorithm under which the public key of the Subject shall be used. The Subject s public key itself is also given in this field. The algorithms and key lengths of the subject keys are described in section Key sizes Version number(s) All issued certificates are X.509 Version 3 certificates, in accordance with the PKIX Certificate and CRL Profile. Page 26

27 7.1.2 Certificate extensions Certificate extensions will be supported in accordance with RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. In general, following extension may be used in a Subscriber certificate: Extension Authority Extension description and contents Authority key identifier Subject key Identifier Certificate policies CRL distribution points CA CA CA CA The identifier of the issuing CA public key is given in this extension. The identifier can be used to identify the public key that corresponds to the private key used for the signing of the certificate. SHA-1 hash algorithm is used to calculate the identifier. The identifier of the Subject public key that is contained in the certificate is given in this extension. The identifier can be used to pick up those certificates that contain a given public key. SHA-1 hash algorithm is used to calculate the identifier. This extension states the policies according to which the certificate has been issued. The relevant policy is identified based on an individual identifier (object identifier, OID) assigned to the policy document or certain certificate type. The identifiers covered by this CPS have been given in section 1.2 Document name and identification. A URL to CPS location may be given in this extension. This extension gives the location where the CRL is available. The exact addresses of the CRLs corresponding to the different certificate classes are given in section Key usage CA The key usage purposes of the public key contained in the certificate are given in this extension. The CA is not responsible for the use that goes against the given key usage purposes. The key usage extension is optional for TeliaSonera gateway certificates. Purposes KeyCertSign and crlsign are never set. Extended key usage Subject alternative name Authority Info Access CA Subscriber CA This extension contains other key usage purposes of the public key except those contained in the Key usage extension. A key usage purpose given in this extension may be generally known or privately defined for a certain application. The extended key usage purposes of the public keys contained in the Subscriber certificates may include: a) Server authentication b) Server authentication and Client authentication c) Client authentication This extension can be used to relate alternative identification information to the Subject. Subject alternative name information used in the Certificates is described in section Types of names. This extension may contain two values: a) The url to CA-certificate b) OCSP service address as defined by RFC2560 Typically all gateway certificates include the value a) and all gateway certificates with EKU value Server authentication will include the value b) Page 27