Swisscom Digital Certificate Services Certification Policy ... The CP enables users and third parties who rely on the certificate (relying party) to assess the trustworthiness of certificates

Swisscom Digital Certificate Services

Certification Policy (CP) - Level: “Diamond” (qualified) -

Abstract Certification policy for qualified certificates of Swisscom Digital Certificate Services, a service of Swisscom (Schweiz) AG for issuing digital certificates for the creation of electronic signatures in accordance with the Swiss Signatures Act (ZertES)

Name 001_cp_diamond_swisscom_digital_certificate_services_en_2.16.756.1.83.1.2.doc

Version 1.2

Classification Unclassified

Project Name “Hermes”

OID 2.16.756.1.83.1.1

Associated CPS CPS Swisscom Digital Certificate Services OID: 2.16.756.1.83.2.1

Name of the CA Swisscom Diamant CA 1

Owner of the CA Swisscom (Schweiz) AG

CP compliance start: 1 September 2005

Language Version: English (original version in German is legally binding)

Document approval Swisscom Solutions, Head of ICT Security Services

Date signed

Signature

_________________________________________

Copyright Swisscom (Schweiz) AG Certification Policy (CP) for Level „Diamond“ Swisscom Digital Certificate Services

Version 1.2 2/32

Document history

Version Date Changed by Comments/type of change

1.0 4 Aug 2005 Project Team Consolidation of KPMG input

1.1 22. Feb 2008 Project Team Anpassung Logo, div. Erneuerungen

1.2 9.6.2008 M. Limacher Remove OID Typo References Reference Description [1] ZertES: Bundesgesetz über Zertifizierungsdienste im Bereich der elektronischen Signatur

(Federal Act on Electronic Signatures, ZertES) of 19 December 2003, hereinafter referred to as Swiss Signatures Act.

[2] VZertES: Verordnung über Zertifizierungsdienste im Bereich der elektronischen Signatur (Ordinance on Electronic Signatures, VZertES) vom 3. Dezember 2004

[3] TAV: Technical and administrative provisions for certification services with regard to electronic signatures, version 2: 29.7.2005, SR 943.032.1

[4] IETF RFC 3647 (2003): "Internet X.509 Public Key Infrastructure - Certificate Policy and Certification Practices Framework"

[5] ETSI TS 101 456 V1.3.1 (2005-05): Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing qualified certificates

[6] IETF RFC 3280 (2002) “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”

[7] IETF RFC 2560 (1999) “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP”

[8] CPS Swisscom Digital Certificate Services, OID 2.16.756.1.83.2.1 [9] Communiqué of the Federal Act on Electronic Signatures (ZertES) of 3 July 2001


Version 1.2 3/32

Contents

1.1 OVERVIEW............................................................................................................................................ 7 1.2 DOCUMENT IDENTIFICATION ................................................................................................................ 7 1.3 SWISSCOM DIGITAL CERTIFICATE SERVICES PARTICIPANTS ................................................................. 8

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

1.4 CERTIFICATE USAGE ............................................................................................................................. 9 1.4.1 Appropriate certificate uses ............................................................................................................ 9 1.4.2 Prohibited certificate uses............................................................................................................. 10

1.5 POLICY ADMINISTRATION ................................................................................................................... 10 1.6 TERMS AND KEYWORDS...................................................................................................................... 10

2 PUBLICATION AND REPOSITORY RESPONSIBILITIES.............................................................. 13 2.1 REPOSITORIES..................................................................................................................................... 13 2.2 PUBLICATION OF CERTIFICATE INFORMATION..................................................................................... 13 2.3 FREQUENCY OF PUBLICATION ............................................................................................................. 13 2.4 ACCESS CONTROLS ON REPOSITORIES ................................................................................................. 13

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 .................................................................................................. 14 3.1.3 Anonymity / pseudonymity............................................................................................................. 14 3.1.4 Rules for interpreting various name forms.................................................................................... 14 3.1.5 Uniqueness of names..................................................................................................................... 14 3.1.6 Recognition, authentication and role of trademarks ..................................................................... 14

3.2 INITIAL IDENTITY VALIDATION ........................................................................................................... 15 3.2.1 Method for proving possession of private key ............................................................................... 15 3.2.2 Authentication of an organisational entity .................................................................................... 15 3.2.3 Authentication of a natural person................................................................................................ 15 3.2.4 Non-verified information............................................................................................................... 15 3.2.5 Validation of signatory power....................................................................................................... 15 3.2.6 Cross-certification......................................................................................................................... 15

3.3 IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS......................................................... 16 3.3.1 Identification and authentication for routine re-key requests ....................................................... 16 3.3.2 Identification and authentication for re-key after revocation ....................................................... 16

3.4 IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUESTS ................................................ 16 4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS................................................ 16

4.1 CERTIFICATE APPLICATION................................................................................................................. 16 4.1.1 Acceptance of certificate applications .......................................................................................... 16 4.1.2 Enrolment process......................................................................................................................... 16

4.2 CERTIFICATE APPLICATION PROCESSING............................................................................................. 17 4.2.1 Performing identification and authentication functions................................................................ 17 4.2.2 Approval or rejection of certificate applications .......................................................................... 17 4.2.3 Processing time ............................................................................................................................. 17

4.3 CERTIFICATE ISSUANCE ...................................................................................................................... 17 4.3.1 Other checks performed by the certification authority.................................................................. 17 4.3.2 Notifying the certificate applicant................................................................................................. 17

4.4 CERTIFICATE ACCEPTANCE................................................................................................................. 18 4.4.1 Acceptance of the certificate ......................................................................................................... 18 4.4.2 Publication of the certificate ......................................................................................................... 18 4.4.3 Notification to other entities.......................................................................................................... 18


Version 1.2 4/32

4.5 KEY PAIR AND CERTIFICATE USAGE .................................................................................................... 18 4.5.1 Subscriber private key and certificate usage................................................................................. 18 4.5.2 Relying party public key and certificate usage.............................................................................. 18

4.6 CERTIFICATE RENEWAL USING THE OLD KEY ...................................................................................... 19 4.6.1 Circumstances for certificate renewal .......................................................................................... 19 4.6.2 Applying for a certificate renewal................................................................................................. 19 4.6.3 Processing certificate renewal requests........................................................................................ 19 4.6.4 Notification to the subscriber ........................................................................................................ 19 4.6.5 Acceptance of a renewal certificate .............................................................................................. 19 4.6.6 Publication of the renewal certificate ........................................................................................... 19 4.6.7 Notification of renewal certificate to other entities....................................................................... 19

4.7 CERTIFICATE RENEWAL USING A NEW KEY (RE-KEY) .......................................................................... 19 4.7.1 Circumstances for certificate re-key ............................................................................................. 19 4.7.2 Applying for a re-key..................................................................................................................... 20 4.7.3 Processing certificate re-key requests........................................................................................... 20 4.7.4 Notification of the new certificate issuance to the subscriber ....................................................... 20 4.7.5 Acceptance of a re-keyed certificate.............................................................................................. 20 4.7.6 Publication of the re-keyed certificate .......................................................................................... 20 4.7.7 Notification of re-keyed certificate to other entities ...................................................................... 20

4.8 CERTIFICATE MODIFICATION .............................................................................................................. 21 4.8.1 Circumstances for certificate modification ................................................................................... 21 4.8.2 Requesting a certificate modification............................................................................................ 21 4.8.3 Processing certificate modification requests................................................................................. 21 4.8.4 Notification of the certificate modification to subscriber.............................................................. 21 4.8.5 Acceptance of a modified certificate ............................................................................................. 21 4.8.6 Publication of the modified certificate .......................................................................................... 21 4.8.7 Notification of certificate modification to other entities................................................................ 21

4.9 CERTIFICATE REVOCATION AND SUSPENSION ..................................................................................... 21 4.9.1 Circumstances for revocation ....................................................................................................... 22 4.9.2 Who can request revocation.......................................................................................................... 22 4.9.3 Procedure for revocation request.................................................................................................. 22 4.9.4 Revocation request grace period for subscriber ........................................................................... 22 4.9.5 Time within which CA must process the revocation request ......................................................... 22 4.9.6 CRL checking requirements for relying parties ............................................................................ 22 4.9.7 CRL issuance frequency ................................................................................................................ 22 4.9.8 Maximum latency for CRLs........................................................................................................... 23 4.9.9 On-line revocation/status checking availability ............................................................................ 23 4.9.10 On-line revocation/status checking requirements .................................................................... 23 4.9.11 Other forms of revocation advertisements available................................................................ 23 4.9.12 Compromising of private keys .................................................................................................. 23 4.9.13 Circumstances for suspension .................................................................................................. 23 4.9.14 Who can request suspension..................................................................................................... 23 4.9.15 Procedure for suspension request ............................................................................................ 23 4.9.16 Limits on suspension period ..................................................................................................... 23

4.10 CERTIFICATE STATUS SERVICE............................................................................................................ 23 4.10.1 Operational characteristics...................................................................................................... 23 4.10.2 Service availability ................................................................................................................... 23 4.10.3 Optional features ...................................................................................................................... 24

4.11 TERMINATION OF CONTRACT BY THE SUBSCRIBER.............................................................................. 24 4.12 KEY ESCROW AND RECOVERY............................................................................................................. 24

5 INFRASTRUCTURE, ORGANISATION AND PERSONNEL SECURITY CONTROLS............... 24 6 TECHNICAL SECURITY CONTROLS ................................................................................................ 24


Version 1.2 5/32

7 CERTIFICATE, CRL AND OCSP PROFILES..................................................................................... 24 7.1 CERTIFICATE PROFILE......................................................................................................................... 24

7.1.1 Certificate extensions .................................................................................................................... 25 7.2 CRL PROFILE ...................................................................................................................................... 25

7.2.1 CRL version number ..................................................................................................................... 25 7.2.2 CRL entry extensions..................................................................................................................... 25

7.3 OCSP PROFILE.................................................................................................................................... 25 8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS ..................................................................... 26

8.1 FREQUENCY AND CIRCUMSTANCES OF THE ASSESSMENT.................................................................... 26 8.2 IDENTITY OF THE ASSESSOR................................................................................................................ 26 8.3 ASSESSOR’S RELATIONSHIP TO ASSESSED ENTITY............................................................................... 26 8.4 TOPICS COVERED BY ASSESSMENT...................................................................................................... 26 8.5 ACTIONS TAKEN AS A RESULT OF DEFICIENCY .................................................................................... 27 8.6 COMMUNICATION OF RESULTS............................................................................................................ 27

9 GENERAL PROVISIONS........................................................................................................................ 27 9.1 FEES ................................................................................................................................................... 27 9.2 FINANCIAL RESPONSIBILITY................................................................................................................ 27

9.2.1 Insurance coverage ....................................................................................................................... 27 9.2.2 Insurance coverage for subscribers and RAs................................................................................ 27

9.3 CONFIDENTIALITY OF BUSINESS INFORMATION................................................................................... 27 9.3.1 Scope of confidential information ................................................................................................. 27 9.3.2 Information not within the scope of confidential information ....................................................... 27 9.3.3 Responsibility to protect confidential information ........................................................................ 28

9.4 PROTECTION OF PERSONAL INFORMATION .......................................................................................... 28 9.4.1 Private information not within the scope of confidential information........................................... 28 9.4.2 Responsibility to protect private information................................................................................ 28 9.4.3 Use of private information ............................................................................................................ 28 9.4.4 Disclosure pursuant to judicial or administrative process............................................................ 28 9.4.5 Other information disclosure circumstances................................................................................. 28

9.5 INTELLECTUAL PROPERTY RIGHTS ...................................................................................................... 29 9.6 REPRESENTATIONS AND WARRANTIES ................................................................................................ 29

9.6.1 CA representations and warranties............................................................................................... 29 9.6.2 RA contracting partner /RA representations and warranties........................................................ 29 9.6.3 Subscriber representations and warranties................................................................................... 29 9.6.4 Relying party representations and warranties .............................................................................. 29 9.6.5 Representations and warranties of other participants .................................................................. 29

9.7 DISCLAIMERS OF WARRANTIES ........................................................................................................... 30 9.8 LIABILITY OF SWISSCOM SOLUTIONS.................................................................................................. 30 9.9 LIMITATIONS OF LIABILITY ................................................................................................................. 30 9.10 TERM AND TERMINATION.................................................................................................................... 30

9.10.1 Term ......................................................................................................................................... 30 9.10.2 Termination .............................................................................................................................. 31 9.10.3 Effects of termination ............................................................................................................... 31

9.11 INDIVIDUAL NOTICES AND COMMUNICATION WITH PARTICIPANTS...................................................... 31 9.12 POLICY AMENDMENTS ........................................................................................................................ 31 9.13 DISPUTE RESOLUTION PROVISIONS ..................................................................................................... 31 9.14 APPLICABLE LAW AND PLACE OF JURISDICTION.................................................................................. 31 9.15 COMPLIANCE WITH APPLICABLE LAW ................................................................................................. 32 9.16 OTHER PROVISIONS............................................................................................................................. 32

9.16.1 Scope and applicability ............................................................................................................ 32 9.16.2 Assignment of rights and obligations ....................................................................................... 32


Version 1.2 6/32

Introduction

This document describes the Certification Policy (hereinafter referred to as CP) of Swisscom Digital Certificate Services, a service of Swisscom (Schweiz) AG [hereinafter referred to as Swisscom Solutions], and concerns the issuing of qualified certificates in accordance with the Swiss Signatures Act, ZertES [1] and the referenced technical and administrative implementation guidelines, TAV[3] and VZertES [2].

The CP enables users and third parties who rely on the certificate (relying party) to assess the trustworthiness of certificates issued by Swisscom Solutions and its RA contracting partners.

A certificate is a form of electronic confirmation which is used to assign a public cryptographic key to a person in order to confirm the identity of the person or organisation. A certificate therefore creates a binding between a person or organisation and a cryptographic key.

The term “qualified”, when used to refer to electronic signatures and certificates, means that a service provider fulfils the requirements of the Signatures Act (ZertES [1]), the Ordinance on Electronic Signatures (VZertES [2]) and the technical and administrative provisions on certification services with regard to electronic signatures of 6/12/2004 (TAV [3]). Compliance with these provisions is assessed by a certifying authority accredited by the Swiss Accreditation Service (SAS). The accredited provider of certification services (hereinafter referred to as CA) is then entitled to offer secure signature creation devices (SSCD) and certificates for the creation and verification of “qualified” signatures. When the Swiss Signatures Act came into effect on 1/1/2005, article 14, paragraph 2bis of the Swiss Cod of Obligations (OR) was introduced, which accords equal status to the qualified electronic signature as a person’s hand-written signature, thus enabling declarations of intent (in particular for the conclusion of contracts) which require the written form to become legally binding with a qualified electronic signature.

OR Art. 14 Para 2bis reads as follows: “The qualified electronic signature based on a qualified certificate issued by an accredited provider of certification services in accordance with the Swiss federal Act of 19 December 20031 has equal status as a hand-written signature, subject to legal or contractual regulations to the contrary.”

A certificate is only as trustworthy as the procedure that is used to create it. Swisscom Solutions therefore divides certificates into “certificate classes”. The higher the certificate class, the more extensive the identification checks on which the issuing of a certificate is based. The certificates themselves contain information on the certificate class. To obtain the highest class of certificate, the qualified certificate, a person needs to go to a registration authority in person and provide official IDs and documents to back up all the information to be indicated on the certificate. The detailed verification procedures on which a certificate class is based and the general security measures adopted can be found in the Swisscom Digital Certificate Services Certificate Practice Statement (hereinafter referred to as CPS).

This CP refers to the highest certificate class, the “qualified digital certificate”, and meets the requirements of the Swiss Signatures Act. For all certificates issued in relation to this CP, the object identifier is indicated in the certificate in accordance with X.509 [OID]. This means that the CP is linked to a certificate of a specific class.

1 SR 943.03; AS 2004 5085


Version 1.2 7/32

1.1 Overview

This qualified CP was drafted by Swisscom Solutions for the following purpose:

• To meet the requirements of a Certificate Service Provider (hereinafter referred to as CSP) of qualified certificates in accordance with ZertES [1]

• To describe the services, roles, limitations and obligations related to the use of qualified certificates issued by Swisscom Digital Certificate Services

• To guarantee interoperability in the use of qualified certificates issued by Swisscom Digital Certificate Services

The CP is based on the guidelines set out in RFC 3647 [4].

To facilitate international cooperation with other certification authorities, this English translation of the CP has been made available; however, the most recent German version always takes precedence.

1.2 Document Identification

Identification

• Title: Certification Policy (CP) of Swisscom Digital Certificate Services

• Version: 1.2

• Object identifier (OID): 2.16.756.1.83.1.1

• OID composition:

Posi

tio

n 1

Posi

tio

n 2

Posi

tio

n 3

Posi

tio

n 4

Posi

tio

n 5

Posi

tio

n 6

Posi

tio

n 7

Meaning

2 Joint ISO-CCITT Tree

16 Country

756 Switzerland

1 Identifies organisation names (RDN)

83 Swisscom Digital Certificate Services 2

1 Level Qualified (Diamond)

1 Certification Policy (CP)

The OIDs assigned by OFCOM for the different categories can be found on the OFCOM Internet site under “RDN number” (relative distinguished number) (http://www.e-ofcom.ch).

2 Assigned by the Federal Office of Communications (OFCOM)


Version 1.2 8/32

1.3 Swisscom Digital Certificate Services participants

1.3.1 Certification authorities

As an accredited provider of certification services, Swisscom Solutions operates an off-line root certification authority (hereinafter CA) and a sub-root CA for qualified certificates (“Diamond”). The Diamond CA only issues certificates for natural persons.

The operation of the CA and its division of roles is subject to the provisions of the TAV [3].

This CP refers exclusively to the highest certificate class, the qualified digital certificate (Diamond), and complies with the requirements of the Swiss Signatures Act. For the sake of completeness the three levels (security levels) offered by Swisscom Digital Certificate Services are described below:

They are:

• “Diamond” (qualified) meets the requirements stipulated in ZertES, uses a secure signature creation device (SSCD) and is used for creating legally binding signatures. This level of certificate is only issued to natural persons and can only be used as a signature.

• “Sapphire” corresponds to the definitions set out in ZertES (article 2, clause B) for advanced certificates and also uses a secure signature creation device (hereinafter SSCD). This type of certificate is used for creating signatures which are not required in the written form or for purposes which have been agreed by the parties. This level of certificate is issued for natural persons and organisations and can be used for signing, authenticating, etc.

• “Ruby” are certificates, that may be created and delivered without usage of a SSCD. In accordance with the certificate requestor the cryptographic keys may be stored in the system (key backup). This level of certificate is issued for natural persons and organisations and can be used for signing, encrypting, authenticating, etc.

The infrastructure is arranged as follows (this CP only covers the “Diamond” certificate class):

ServiceseCertificatgitalSwisscomDi

otCustomerRo

Private keysPublic keys

Figure 1: Hierarchical layout of CAs

Root signed by RSA


Version 1.2 9/32

1.3.2 Registration authorities

The Swisscom Solutions business model is based on a registration authorities (hereinafter RA) contracting partner model. Contracting partners of Swisscom Solutions assume the role of RA. It must be ensured that:

• The certificates offered are optimally integrated in the respective partner application

• The user can obtain a certificate in the simplest possible manner

• Certificates of Swisscom Digital Certificate Services can be used by several service providers

The RA contracting partners have a contractual obligation to comply with all the requirements set out in TAV [2], clause 3.4.1 Registration, administration and revocation of certificates for third parties.

RAs which issue “qualified” certificates are monitored by the certification authority to ensure that the provisions (TAV [3]) are being adhered to.

The RA operator must provide the CA with written evidence that the relevant CP is being complied with. The roles and responsibilities of the RA also need to be documented and communicated by the certificate service provider.

1.3.3 Subscribers

Certificates can be issued to natural persons in line with the usage guidelines of Swisscom Solutions or the RA contracting partner.

1.3.4 Relying parties

Relying parties are natural persons or organisations which use certificates issued by Swisscom Digital Certificate Services to verify the identity of a subscriber with whom they exchange information electronically. A relying party can be – but does not have to be – a participant of Swisscom Digital Certificate Services.

1.3.5 Other participants

Other participants can be natural persons or legal entities who are involved in the certification or registration process as service providers. The commissioning subscriber is responsible for service providers acting on behalf of a subscriber or relying party.

Service provision agreements with service providers acting on their own behalf can only be concluded by the service management of Swisscom Digital Certificate Services.

1.4 Certificate usage

1.4.1 Appropriate certificate uses

Certificates issued within the scope of this CP can be used by subscribers as electronic signatures. Subscribers are responsible for how certificates are used in their own application programs. For a qualified signature to be valid the procedures and methods defined by Swisscom Digital Certificate Services must be applied. The application programs being used must also take into account any necessary security requirements. Application programs are not installed by Swisscom Digital Certificate Services or its contracting partners.


Version 1.2 10/32

1.4.2 Prohibited certificate uses

In accordance with ZertES and the implementation guidelines (TAV [3]) and ETSI TS 101 456 [5] section 7.2.5) qualified certificates can only be used for creating signatures. All other uses are prohibited.

1.5 Policy administration

The document framework is administered by:

Swisscom (Schweiz) AG Digital Certificate Services Müllerstrasse 16 8004 Zurich

1.6 Terms and keywords

Term Explanation Certification service provider or certification authority (CA)

Authority which confirms information in an electronic environment and issues digital certificates for this purpose.

Authentication authority Authority accredited in accordance with the accreditation law to certify and monitor providers of certification services.

Certification Practice Statement (CPS) Statement on the rules and practices that a CA employs in issuing certificates of the certificate class referred to. The CPS defines the devices, the policy and the procedures used by the CA in issuing and managing qualified certificates in accordance with ZertEs [1].

Relying parties Person or process which relies on the electronic signatures verified when using a certificate.

Digital certificate Permanent electronic certificate that links a signature verification key with the name of a person. In this document the term “certificate” is understood to mean “qualified certificate”.

Electronic signature or signature Data in electronic form that is added to other electronic data or linked to it logically in order to authenticate such data.

Generation of certificates Service provided by the CA; generation of a digital certificate based on the name of the certificate applicant and his/her attributes, which are verified during registration.

Subscriber Natural person who owns the signature key and who is assigned the signature verification key in the certificate.

Certificate revocation list (CRL) A list signed by the CA containing the serial numbers of all certificates which have been declared invalid before their validity has expired.


Version 1.2 11/32

Term Explanation Qualified electronic signature Electronic signature meeting the following

requirements: 1. It is only assigned to the subscriber; 2. It enables the subscriber to be identified; 3. It is generated using methods which the subscriber

can keep under his/her own control; 4. It is generated by a secure signature creation device

in accordance with article 6, sections 1 and 2 of ZertES;

5. It is linked to data to which it is related in such a way that subsequent changes to the data can be detected;

6. It is based on a qualified certificate that is valid at the time of creation.

Qualified certificate Digital certificate meeting the requirements of article 7 of ZertES.

Registration CA service that verifies the identity and if necessary the attributes of each certificate applicant before his/her certificate is created or the activation data (or password) for activating the usage of the signature key is assigned.

Key pair Signature key and associated signature verification key which are linked mathematically through an asymmetrical signature algorithm.

Secure signature creation device: Device in accordance with article 6, section 2 of ZertES, configured for implementing the signature key that the subscriber uses to create an electronic signature.

Security policy (SP): Body of rules and practices assembled on the basis of a risk analysis for reducing the probability of potential incidents (preventative measures) and for rectifying the effects of such incidents (corrective measures) in order to protect the resources of the electronic certification service provider that have been identified as needing protection. The security strategy and policy are used to clearly define the target security level for an information system and especially for each element within the security architecture.

Signature verification key Data such as codes or public cryptographic key used for verifying an electronic signature.

Signature key Unique data, such as codes or private cryptographic key, used by the subscriber for creating an electronic signature.

Certificate revocation Service of the certification service provider which terminates the validity of a certificate before it is due to expire

Certificate issuance Service of the certification service provider that makes the generated certificate available to the subscriber and – if authorised by the subscriber – the certificate users.


Version 1.2 12/32

Term Explanation Certificate status management Service of the certification service provider used by

certificate users to check if a certificate has been revoked.

Time stamp Certification service provider service which provides a stamp with the date, time and qualified signature of the CA, indicating a specific point of time in which specific digital data existed.

Certification authority (CA) See “Certification services provider” Certification policy (CP) A complete set of rules that indicates the applicability of

a certificate to a particular community and/or class of application with common security requirements.

Terms and abbreviations

Term Explanation CA Certification Authority CP Certification Policy CPS Certificate Practice Statement CSP Certificate Service Provider CRL Certificate Revocation List ZertES Bundesgesetz über Zertifizierungsdienste im Bereich der elektronischen Signatur

(Federal Act on Electronic Signatures) of 19 December 2003 (see [1]) VZertES Verordnung über Zertifizierungsdienste im Bereich der elektronischen Signatur

(Ordinance on Electronic Signatures, VZertES) of 3 December 2004 SSCD Secure Signature Creation Device in accordance with ETSI TS 101 456 OCSP Online Certificate Status Protocol DN Distinguished name in accordance with RFC 3739 CN Common name, as part of the DN RA Registration Authority Hash The hash function is a cryptographic check sum for a text to ensure its integrity.

The procedure is used to reduce the time needed to calculate the encryption of data in the public key process. A hash function that generates a check sum of a fixed length, the hash value, is used for a message with a variable length. This enables the integrity of a message to be positively determined.


Version 1.2 13/32

2 Publication and repository responsibilities

2.1 Repositories

As CSP, Swisscom Digital Certificate Services ensures that information required for validating the certificates it issues is available free of charge via a Web interface and an LDAP request (ZertES[1], art. 11, sec. 1 ). Additional status services are listed in section 2.1 of the CPS [8].

Revoked certificates are entered in certificate revocation list (hereinafter referred to as CRL). The CRL is updated every 24 hours.

Details can be found in sections 2.2 and 2.3 of the CPS [8].

2.2 Publication of certificate information

As CSP, Swisscom Digital Certificate Services publishes the following information:

• The root certificate of Swisscom Digital Certificate Services and its finger print

• Certificates of the CA and responsible registration authorities together with their finger prints

• This CP and the associated CPS [8].

In addition, subscribers are provided with information on Swisscom Digital Certificate Services, on the correct application of cryptography and the use of certificates. Addresses where this information and any other services can be obtained are included in section 2.2. of the CPS [8].

2.3 Frequency of publication

Swisscom Digital Certificate Services updates certificate validation information at regular intervals. The period between updates must not exceed 24 hours. Details can be found in section 2.3 of the CPS [8].

2.4 Access controls on repositories

Unrestricted read-only access is available to all the information referred to in sections 2.1 and 2.2. Bulk or wildcard searches are not supported. Write access to this information can only be granted to authorised persons. Details can be found in section 2.4 of the CPS [8].

3 Identification and authentication

3.1 Naming

3.1.1 Types of names

A uniform naming hierarchy is employed. All certificates issued by Swisscom Digital Certificate Services have a unique name (distinguished name, hereinafter referred to as DN) in accordance with the X.500 standard. A DN contains a sequence of uniquely identifiable naming attributes which are used to reference all participants of a hierarchy.

Details of the specific naming forms are defined in section 3.1.1 of the CPS [8].


Version 1.2 14/32

3.1.2 Need for names to be meaningful

The DN must uniquely identify the subscriber and be in a form that is meaningful to people. The following basic rules apply when assigning names:

• Certificates may only be issued to an acceptable name of the subscriber.

• When assigning names for pseudonyms it must be ensured that confusion is avoided between natural persons and legal entities or organisational IDs. In addition, DNS names, IP addresses or other syntax elements used within Swisscom Digital Certificate Services may also not be used. A pseudonym must not contain defamatory or offensive content or violate legal regulations or the rights of third parties (e.g. naming rights). All forms of discrimination are prohibited.

In addition, all certificates are assigned a unique serial number so as to provide a clear and distinct reference to the subscriber. Details are set out in section 3.1.2 of the CPS [8].

3.1.3 Anonymity / pseudonymity

In justified circumstances a natural person can be assigned a pseudonym instead of the name in the certificate. This is indicated clearly in the common name (CN) field of the DN. Details are regulated in section 3.1.3 of the CPS [8]. The uniqueness of pseudonyms is also subject to the regulations in section 3.1.5.

The identity check is always performed in accordance with the rules set out in 3.2. Anonymous certificates are therefore not possible.

3.1.4 Rules for interpreting various name forms

The character set to be used and the substitution rules for special symbols are described in section 3.1.4 of the CPS [8].

3.1.5 Uniqueness of names

Before a certificate can be issued, the accuracy of the DN details must be checked by the registration authority using official identification documents. The uniqueness of the given name must be checked by the CA responsible. A subscriber’s DN must be unique and must not be assigned to different subscribers. Only when a subscriber possesses a number of certificates with different key uses can a DN appear several times, although the respective serial numbers of the issuing CA always remain unique.

3.1.6 Recognition, authentication and role of trademarks

If the DN on the certificate refers explicitly to a natural person the recognition of trademarks is not relevant. In all other cases the subscriber is responsible for ensuring that the choice of name does not infringe on any trademark rights, etc. The CA is not obliged to check such rights. The subscriber alone is responsible for making such checks. If the CA is informed about an violation of such rights the certificate will be revoked.


Version 1.2 15/32

3.2 Initial identity validation

3.2.1 Method for proving possession of private key

The private key is generated in a secure signature creation device in the trust centre of the CSP or a contracting partner. The procedure is described in 3.2.1 of the CPS [8].

3.2.2 Authentication of an organisational entity

This is not applicable as ZertES stipulates that qualified certificates can only be issued to natural persons.

3.2.3 Authentication of a natural person

The following procedure is used for verifying the identity of natural persons (even ones that use a pseudonym) requesting a qualified certificate:

1. The certificate applicant goes in person to the RA responsible and submits one or more official IDs containing photographs (personal ID, passport, certificate from the local residents’ registration office) for performing the identification check.

2. An RA employee performs the identity check using one or more official IDs containing a photograph (personal ID, passport, certificate from the residents’ registration office) and documents the procedure. The RA contracting partner must be in possession of a conformity statement for the correct implementation of the identification by a certification authority recognised by the Swiss Accreditation Service (SAS). In addition, the correct conduct is made legally binding by contract.

3. All attributes indicated in the certificate must be proved and confirmed by an official document (article 8 of ZertES, article 5, section 2 of VZertES).

If the applicant already has a valid certificate, and provided the person’s identity has not changed, other certificates for this person can also be applied for by sending an encrypted and signed application. Prerequisite for this type of application is that no more than three years have elapsed since the initial application for the valid certificate was made and that the identification documents submitted are still valid.

3.2.4 Non-verified information

All information required for the identity check is examined (section 3.2.3). No additional information is examined.

3.2.5 Validation of signatory power

This is not applicable as ZertES stipulates that qualified certificates can only be issued to natural persons.

3.2.6 Cross-certification

Cross-certification is not permitted in Switzerland in accordance with the ZertES communiqué [9].


Version 1.2 16/32

3.3 Identification and authentication for re-key requests

3.3.1 Identification and authentication for routine re-key requests

A routine certificate renewal requires that the subscriber be in possession of a valid certificate from the CA responsible. The subscriber also needs to apply for the re-key before the validity of the certificate being replaced expires. If all the documents used for identification are still up to date and valid and a valid certificate is available, no other measures are necessary. In all other cases, the procedure is the same as for a new application (3.2).

3.3.2 Identification and authentication for re-key after revocation

Certificates that have been revoked cannot be renewed. An application for a new certificate needs to be made. The procedure is described in section 3.2.

3.4 Identification and authentication for revocation requests

The subscriber must be provided with an adequate procedure for making a request to the issuing CA or relevant registration authority for a certificate to be revoked. The certificate can be revoked in writing or over the phone by giving the authorisation information agreed with the RA. Certificates can also be revoked electronically if specific conditions are met. Details can be found in section 3.4 of the CPS [8].

4 Certificate life-cycle operational requirements

4.1 Certificate application

4.1.1 Acceptance of certificate applications

Certificate applications are submitted to the RA contracting partner of Swisscom Digital Certificate Services, who are authorised to issue certificates to the applicant subject to the conditions in 1.3.3 being met.

4.1.2 Enrolment process

A certificate can only be generated by a CA once the enrolment process at a registration authority of an RA contracting partner has been successfully concluded. The documentation of the enrolment process of natural persons includes at least the following:

• Certificate application

• Copy of all submitted identification documents containing a current photograph

• Confirmation by the certificate applicant that he has read and understood the customer contract (together with all its constituent parts such as service description, usage conditions, general terms and conditions).

• Statement as to whether the information in the certificate can be made public.


Version 1.2 17/32

4.2 Certificate application processing

4.2.1 Performing identification and authentication functions

The relevant registration authority of the RA contracting partner performs the identification and authentication of a certificate applicant in accordance with the procedure described in section 3.2.

4.2.2 Approval or rejection of certificate applications

The certificate application is accepted by the registration authority or CA if the following criteria are met:

• Submission of all necessary documents (see section 4.1.2)

• Payment of any agreed fees (see section 9.1).

When the above criteria have been successfully applied and the identification and authentication have been performed the certificate application is processed by the issuing CA.

If the above criteria cannot be met or the identification and authentication of a certificate applicant is unsuccessful the certificate application is not processed. The facts of the case are documented and passed on to the applicant together with the reasons for rejecting the application.

4.2.3 Processing time

The processing time is set out in section 4.2.3 of the CPS [8].

4.3 Certificate issuance

Once a certificate application has been accepted and successfully verified (4.2.2):

• The CA issues a “Diamond” class qualified certificate.

• The SSCD and private key is either handed to the applicant in person or delivered via secure means.

• The applicant is informed about this process (see 4.3.2).

• The applicant is instructed on the correct use of the cryptographic device

• A service description with the rights and obligations of the parties is issued.

4.3.1 Other checks performed by the certification authority

The formal conditions for issuing a certificate are appropriately checked by the CA. No other checks are made.

4.3.2 Notifying the certificate applicant

Once the certificate has been issued, it is dispatched to the certificate applicant in an appropriate manner together with the secure signature creation device. If the certificate applicant does not collect the secure signature creation device in person, it is delivered in an appropriately secure manner. Procedures are described in section 4.3 of the CPS [8].


Version 1.2 18/32

4.4 Certificate acceptance

On receipt, the subscriber is obliged to verify the accuracy of his own certificate and the certificate of the issuing CA.

4.4.1 Acceptance of the certificate

A certificate is deemed as accepted by the subscriber if

• the certificate is used or

• no objection is made within a period of time specified in section 4.4.1 of the CPS [8].

The issuing RA must immediately contact the CA to revoke erroneously issued certificates.

4.4.2 Publication of the certificate

The rules in section 2.1 apply.

4.4.3 Notification to other entities

There is no provision for notifying other entities.

4.5 Key pair and certificate usage

The scope of application of certificates issued within the context of this CP is described in section 1.4. In accordance with ZertES, qualified digital certificates can only be used for creating electronic signatures.

4.5.1 Subscriber private key and certificate usage

By accepting the certificate the subscriber assures all participants of Swisscom Digital Certificate Services and all parties who rely on the trustworthiness of the information contained in the certificate that

• he has an appropriate understanding of how certificates are used and applied,

• all details and declarations provided by the subscriber relating to the information contained in the certificate are true,

• the private key will be kept securely,

• no unauthorised persons will be granted access to the private key,

• the certificate will only be used in accordance with this CP,

• the certificate will be immediately revoked if the details of the certificate are no longer correct or the private key is mislaid, stolen or otherwise compromised.

4.5.2 Relying party public key and certificate usage

Anyone using a certificate that has been issued within the context of this CP for verifying a signature or for purposes of authentication should

• have a fundamental understanding of how certificates are used and applied,

• have checked the validity of a certificate before using it and

• only use the certificate for authorised and legal purposes in compliance with this CP.


Version 1.2 19/32

4.6 Certificate renewal using the old key

When a certificate is renewed the subscriber is issued a new certificate by the relevant RA (RA contracting partner) based on a new key pair.

Swisscom Digital Certificate Services does not support the creation of new certificates using the old key (certificate renewal) for qualified certificates.

4.6.1 Circumstances for certificate renewal

Not Applicable

4.6.2 Applying for a certificate renewal

Not Applicable

4.6.3 Processing certificate renewal requests

Not Applicable

4.6.4 Notification to the subscriber

Not Applicable

4.6.5 Acceptance of a renewal certificate

Not Applicable

4.6.6 Publication of the renewal certificate

Not Applicable

4.6.7 Notification of renewal certificate to other entities

Not Applicable

4.7 Certificate renewal using a new key (re-key)

A certificate renewal always involves the creation of a new key pair. The lifecycle of the certificate and key are the same. (3 years).

A new certificate is always issued on a new secure signature creation device. The key length and algorithm used are the ones that are currently up to date and which are stipulated for use in the applicable CPS [8], 7.1. The subscriber must confirm that the information in the certificate has not changed and that the IDs and documents submitted for issuing the certificate are still valid. When the new certificate is issued the old certificate is not revoked and remains valid until the period of validity expires.

4.7.1 Circumstances for certificate re-key

A certificate renewal with a new key pair (re-key) can be requested if the validity of the certificate and key have expired or the key length or algorithm used are no longer considered adequate.


Version 1.2 20/32

4.7.2 Applying for a re-key

A certificate renewal with a new key pair (re-key) is usually requested by the subscriber or initiated directly by the RA contracting partner; it is up to the CA whether or not to actively support a certificate renewal. The relevant procedures are described in section 4.6.2 of the CPS [8].

4.7.3 Processing certificate re-key requests

The procedure for renewing a certificate with a new key pair (re-key) is described in 4.3; identification and authentication for the re-certification are performed in accordance with the rules set out in section 3.3.1.

4.7.4 Notification of the new certificate issuance to the subscriber

The rules in section 4.3.2 apply.

4.7.5 Acceptance of a re-keyed certificate


4.7.6 Publication of the re-keyed certificate


4.7.7 Notification of re-keyed certificate to other entities



Version 1.2 21/32

4.8 Certificate modification

When a certificate is modified a new certificate with the same key pair is created due to changes in the information in the certificate. If the identity of the subscriber has changed the procedure is the same as with a new application. The old certificate is revoked when the new certificate is issued.

Certificates are only modified if the associated key pair is still valid for at least another 6 months and the identity of the subscriber has not changed. Otherwise the certificate is renewed with a new key pair (rekey).

4.8.1 Circumstances for certificate modification

Circumstances under which certificate modifications can take place are:

• Spelling mistakes during the issuing of the certificate

• Changes in certificate information (e-mail address, organisation)

4.8.2 Requesting a certificate modification

The subscriber must go to the relevant RA in person and submit supporting documentation for the information to be modified.

4.8.3 Processing certificate modification requests

The procedure for renewing a certificate is set out in 4.3; identification and authentication for the certificate modification are performed in accordance with the rules set out in section 3.3.1.

4.8.4 Notification of the certificate modification to subscriber

The subscriber applies for the certificate modification in person and so does not need to receive special notification.

4.8.5 Acceptance of a modified certificate


4.8.6 Publication of the modified certificate


4.8.7 Notification of certificate modification to other entities


4.9 Certificate revocation and suspension

This section explains the circumstances under which a certificate must be revoked. There is no provision for a suspension (time displacement) of certificates (ZertES Art. 10). Once a certificate has been revoked it can no longer be renewed or extended.


Version 1.2 22/32

4.9.1 Circumstances for revocation

Certificates must be revoked by the RA or CA responsible if at least one of the following circumstances is known to exist:

• A certificate contains information that is not (no longer) valid.

• The certificate has been illegally extended.

• The certificate can no longer guarantee that a signature verification key can be assigned to a specific person.

• The private key of the subscriber has been changed, lost, stolen, made public or otherwise compromised or misused.

• The subscriber is no longer entitled to hold the certificate (see 1.3.3).

• The subscriber does not comply with this CP.

• The relevant registration authority (RA) does not comply with this CP or the CPS [8].

• The subscriber no longer requires the certificate in question.

• The certification business is discontinued.

• The subscriber has not kept up his payment commitment even after repeated reminders.

4.9.2 Who can request revocation

Certificates can only be revoked by the issuing RA (RA contracting partner) or the CA. All subscribers can apply to the RA (RA contracting partner) which issued their certificate to have the certificate revoked. Procedures for revoking a certificate are described in section 4.9 of the relevant CPS [8]. The condition for accepting a revocation request is the successful identification and authentication of the subscriber in accordance with section 3.4.

4.9.3 Procedure for revocation request

If the conditions for revoking a certificate are met, the certificate is blocked forthwith.

4.9.4 Revocation request grace period for subscriber

The subscriber must contact the relevant CA without delay and arrange for his certificate to be revoked if there are good reasons for doing so (see 4.9.1).

4.9.5 Time within which CA must process the revocation request

The RA (RA- contracting partner) should process a revocation request immediately if the above conditions exist.

4.9.6 CRL checking requirements for relying parties


4.9.7 CRL issuance frequency

The frequency for updating a CRL is set out in section 4.9.7 of the relevant CPS [8]. However, the CRL is updated at least every 24 hours.


Version 1.2 23/32

4.9.8 Maximum latency for CRLs

The maximum latency for a CRL is set out in section 4.9.8 of the relevant CPS [8].

4.9.9 On-line revocation/status checking availability

Swisscom Digital Certificate Services provides an online procedure for checking the validity of a certificate. All certificates issued by the certification authority must be registered. Details can be found in section 4.9.9 of the relevant CPS [8].

4.9.10 On-line revocation/status checking requirements

The validity of a certificate must always be checked prior to being used. Standards are set out in sections 7.2 (CRL profile) and 7.3 (OCSP profile) of the CPS [8], 4.9.10.

4.9.11 Other forms of revocation advertisements available

Swisscom Digital Certificate Service does not provide any other procedures for obtaining revocation information.

4.9.12 Compromising of private keys

If a private key is compromised, the associated certificate must be revoked immediately. If the private key of a CA is compromised all certificates it has issued are blocked.

4.9.13 Circumstances for suspension

Diamond-class qualified certificates cannot be suspended, as stipulated in ZertES.

4.9.14 Who can request suspension

This is not applicable as Diamond-class qualified certificates cannot be suspended in accordance with ZertES.

4.9.15 Procedure for suspension request

This is not applicable since Diamond-class qualified certificates cannot be suspended in accordance with ZertES.

4.9.16 Limits on suspension period

This is not applicable as Diamond-class qualified certificates cannot be suspended in accordance with ZertES.

4.10 Certificate status service

Details of the procedure, availability and features can be found in section 4.10 of the relevant CPS [8]. The service is usually available around the clock.

4.10.1 Operational characteristics

The operational features are described in section 4.10.1 of the CPS [8].

4.10.2 Service availability

Details about service availability can be found in section 4.10.2 of the CPS [8].


Version 1.2 24/32

4.10.3 Optional features

Optional service features are described in section 4.10.3 of the CPS [8].

4.11 Termination of contract by the subscriber

The term of the contractual relationship is derived from the period of validity stated in the certificate (usually 3 years). Documents and certificates can be stored for 11 years in accordance with the provisions of ZertES.

4.12 Key escrow and recovery

Key escrow and recovery is not permitted for qualified signature keys in accordance with ZertES. Swisscom Digital Certificate Services guarantees that no copies of signature keys shall be created.

5 Infrastructure, organisation and personnel security controls

Infrastructure, organisation and personnel security controls are described in paragraph 5 of the CPS [8]. Some areas may be dealt with in separate documents, which may or may not have been published. All security measures are based on the provisions of ZertES [1], TAV [3] and the other referenced documents, in particular ETSI TS 101 456[5].

6 Technical security controls

Technical security controls are discussed in paragraph 6 of the CPS [8].

7 Certificate, CRL and OCSP profiles

Diamond class qualified certificates issued by Swisscom Digital Certificate Services, the certificate revocation list (CRL) and the online certificate status protocol (OCSP) are based on the provisions of ZertES [1], TAV [3] and the referenced documents, in particular ETSI TS 101 456 [5] and are set out in paragraph 7 of the CPS [8].

7.1 Certificate profile

Diamond class qualified certificates issued by Swisscom Digital Certificate Service include the following required fields as defined in the X.509 v3 standard and in accordance with TAV [3].

• X.509 version of the certificate

• Certificate serial number

• Object identifier of the hash and signature algorithm

• Name of the CA (issuer distinguished name)

• Validity (from – to)

• Name of the subscriber (subject distinguished name)

• Public key of the subscriber

The following certificate extension (in accordance with X 509 V3) is also used:

• Basic constraints: subject type = end entity (critical)

• Name of the CA (issuer field)

Details of the certificate profile can be found in section 7.1 of the CPS [8].


Version 1.2 25/32

7.1.1 Certificate extensions

The following extensions are used, as defined in X.509 v3 and in accordance with TAV [3]:

• Digital signature of the CA (non-critical)

• Purpose of the certificate (critical)

• Certificate guidelines (non-critical)

• CRL distribution point (non-critical)

• Access point for the CA certificate (non-critical)

• Note: qualified certificate (critical)

• Note: private key in SSCD (critical)

• Note: upper limit of a transaction (critical)

7.2 CRL profile

7.2.1 CRL version number

The CRL profile contains the following information in X.509 format, version 2. In accordance with RFC 3280 [6], chapter 5.1, the CA must add the following fields to the tbsCertList sequence in the CRL:

• Version, (value =1 indicates that it is a CRL version 2).

• signature;

• issuer;

• thisUpdate;

• nextUpdate;

• revokedCertificates, including serial numbers of the certificates and date of the revocation.

Details of the CRL profile can be found in section 7.2 of the CPS [8].

7.2.2 CRL entry extensions

In accordance with document RFC 3280 [6], chapter 5.2, the following non-critical extensions are added to tbsCertList sequence in the CRL:

• authorityKeyIdentifier

• add cRLNumber.

7.3 OCSP profile

The OCSP responder replies to OCSP queries on port 80 in accordance with RFC 2560 [7]. The following status messages are supported:


Version 1.2 26/32

Certificate Status Certificate Status Value Comments

Revoked Revoked

Suspended Revoked (not possible for qualified certificates) Active Good

Unknown Unknown

Details of the OCSP profile can be found in section 7.3 of the CPS [8].

8 Compliance audit and other assessments

The CA and the registration authorities of the RA contracting partners that issue qualified certificates are obliged to structure all their processes in accordance with this CP and the CPS [8]. Swisscom Digital Certificates Services can only issue qualified certificates if all the provisions of ZertES [1] and the referenced technical and administrative guidelines have been met. Compliance is checked in accordance with TAV [3], chapter 2 “System for CA certification” by the certification authority accredited by the Swiss Accreditation Service.

8.1 Frequency and circumstances of the assessment

Following the initial audit the certification authority performs an annual recertification. The CSP is also obliged in accordance with TAV[3], chapter 3.2 “Organisation and operational principles”, paragraphs c and d to perform an internal audit annually.

The RA and RA contracting partner are also an integral part of the assessment.

8.2 Identity of the assessor

The initial and annually recurring compliance audit is performed by KPMG, Klynveld Peat Marwich Goerdeler SA, Zurich, a Swisscom-independent company. The assessment can only be carried out by companies that have been accredited by the Swiss Accreditation Service (SAS). A list of accredited companies can be found on the SAS Internet site (http://www.sas.ch/de/sas-index.html ) under “Accredited Bodies”

The internal audit is performed by the company Coreva AG, Sonnenbergstrass 50, CH-8032 on a mandate basis.

8.3 Assessor’s relationship to assessed entity

The internal auditors and the certification authority are independent companies that carry out their assessments on a mandate basis in accordance legal and regulatory guidelines.

8.4 Topics covered by assessment

The topics to be assessed are determined by the certification authority performing the assessment. Risks that make an assessment urgent can be determined in advance.

The internal auditors draw up an assessment plan in collaboration with the certification authority.


Version 1.2 27/32

8.5 Actions taken as a result of deficiency

Any deficiencies found during the assessment shall be swiftly corrected by arrangement between the certification authority carrying out the assessment and the CA or RA being assessed. The deadlines defined in ZertES [1] must be adhered to.

8.6 Communication of results

Action taken to address serious deficiencies shall be communicated to the affected parties without delay.

Results are published in accordance with the provisions of ZertES, article 9.

There is no provision for a general publication of the assessment results.

9 General provisions

9.1 Fees

Fees for services provided by Swisscom Digital Certificate Services or the CA operated by the RA contracting partner are detailed in the pricelist, which can be requested from the contact address in section 1.5. Additional services that are not covered by the pricelist can be billed separately.

9.2 Financial responsibility

9.2.1 Insurance coverage

As part of the General Terms and Conditions of Swisscom Solutions (AGB), which are issued to the subscriber, insurance coverage provided by Swisscom Digital Certificate Services also extends to legal liability claims relating to financial loss in accordance with article 16 of ZertES. Costs incurred by the insured companies in the event of any suspension in business activities in accordance with article 13 of ZertES are also insured. Such damages and costs are subject to a general sub-limit of CHF 2 million per event and CHF 8 million per insurance year. Swisscom (Schweiz) AG, a 100% subsidiary of Swisscom AG, and in turn majority-owned by the Swiss Confederation by law, is an economically robust and stable company.

9.2.2 Insurance coverage for subscribers and RAs

The subscriber and RA are responsible for taking out adequate insurance coverage for their liability obligations relating to signature legislation. The CA can provide them with advice and support on questions concerning insurance options.

9.3 Confidentiality of business information

9.3.1 Scope of confidential information

All information regarding participants and applicants that does not fall under 9.3.2 is classed as confidential information. Such information includes business plans, sales information, information about business partners and all information communicated during the registration process.

9.3.2 Information not within the scope of confidential information

All information contained in the issued certificates and the certificate revocation list, whether explicit (e.g. DN elements, e-mail address) or implicit (e.g. information regarding certification), or which can be derived therefrom is not classed as confidential.


Version 1.2 28/32

9.3.3 Responsibility to protect confidential information

In its role of CA, Swisscom Solutions is responsible for adopting measures to protect confidential information. Information may only be processed as part of the service provision and only disclosed to third parties if a confidentiality agreement has been signed beforehand and the employees involved have undertaken to comply with the legal provisions pertaining to data protection. RA contracting partners who submit and receive information to and from the CA as part of the certificate application process are not considered to be third parties. Documents can be viewed for auditing purposes in the presence of the Swisscom Digital Certificate Services security offer or an appointed representative.

9.4 Protection of personal information

The CA handles personal information in compliance with currently applicable law, and in particular the Telecommunications and Data Protection Acts. The CA only gathers, stores and processes information that is necessary for providing services, for developing and maintaining customer relations (i.e. to guarantee a high-quality service), for ensuring the security of operations and infrastructure and for billing purposes.

The requirements of the Swiss Data Protection Act must be complied with in accordance with article 14 of ZertES [1].

9.4.1 Private information not within the scope of confidential information

Not applicable.

9.4.2 Responsibility to protect private information

Swisscom Solutions and the registration authorities operating on its behalf are obliged to handle private information in compliance with the Data Protection Act (DSG) and the Telecommunications Act (FMG). Private information may only be obtained in accordance with the law and must be processed in good faith and to a reasonable extent. Private information may only be processed for the purpose stated when obtaining it and in compliance with legal provisions (Art. 4 DSG).

Private information must not be used for commercial purposes (Art. 14, sec. 1 ZertES).

9.4.3 Use of private information

The use of private information is not governed by this CP.

9.4.4 Disclosure pursuant to judicial or administrative process

The CA of Swisscom Digital Certificate Services is subject to Swiss law and is obliged to disclose customer information to government authorities in accordance with applicable law if requested to do so.

9.4.5 Other information disclosure circumstances

Information is not disclosed to third parties in any other circumstances.


Version 1.2 29/32

9.5 Intellectual property rights

Swisscom Solutions is the owner of the intellectual property rights of the following documents:

• The present CP

• The associated CPS [8]

• Trademark rights, in particular regarding Swisscom Digital Certificate Services, and the remaining contract documents.

Swisscom Solutions authorises the RA contracting partners and subscribers to forward the above-named documents unaltered to third parties. Additional rights are not granted. In particular, the forwarding of modified versions and insertion in other documents or publications without written consent from Swisscom Solutions is prohibited.

9.6 Representations and warranties

9.6.1 CA representations and warranties

Swisscom Solutions undertakes in its role as CA to perform all the tasks described in this CP and the associated CPS [8] for the implementation of the provisions of ZertES and all other implementation provisions (TAV [3]).

9.6.2 RA contracting partner /RA representations and warranties

The Swisscom Digital Certificate Services business model provides for an RA contracting partner model. In this regard, contracting partners assume the role of RA. It must be ensured that:

• The certificates provided are optimally integrated in the relevant applications of the RA contracting partner.

• The certificate applicant receives a certificate in the simplest possible manner

• Certificates of Swisscom Digital Certificate Services can be used by various service providers

The RA contracting partners are contractually obliged to comply with all requirements pursuant to the Signatures Act and the TAV [3], chapter 3.4.1 Registration, administration and revocation of certificates for third parties.

All RA contracting partners operating on behalf of Swisscom Solutions are obliged by Swisscom Solutions to perform all the tasks and duties described in this CP and the associated CPS [8]

9.6.3 Subscriber representations and warranties


9.6.4 Relying party representations and warranties


9.6.5 Representations and warranties of other participants

If other participants are involved as service providers in the certification process, Swisscom Solutions is responsible in its role as CA for ensuring that the service providers comply with the CP and CPS [8].


Version 1.2 30/32

9.7 Disclaimers of warranties

The scope of the warranty is set out in ZertES.

9.8 Liability of Swisscom Solutions

As CA, Swisscom Solutions is liable to the subscriber of the signature key and any third parties who rely on a valid qualified certificate in accordance with article 16 of ZertES for damages they sustain on account of Swisscom Solutions’ failure to meet its obligations regarding the Signatures Act or implementation provisions. The onus is on Swisscom Solutions to prove that it has fulfilled its obligations regarding the ZertES and the implementation provisions.

Swisscom Solutions is not liable for damages arising from the non-compliance with or transgression of a usage restriction contained in the certificate.

In all other instances Swisscom Solutions shall be liable as follows: In the event of any breach of contract, Swisscom Solutions shall be liable for any proven damage, unless Swisscom is able to prove that the damage was sustained through no fault of its own. Swisscom Solutions shall have unlimited liability for damages arising from intentional conduct or gross negligence. In the event of simple negligence, Swisscom Solutions shall be liable for personal injury up to an unlimited amount; for material damage up to CHF 500,000 per event and calendar year. In the event of simple negligence, Swisscom Solutions shall be liable for financial loss up to the equivalent value of the agreed services provided during the current year of contract, up to a maximum of CHF 50,000 per event and calendar year. Swisscom Solutions shall under no circumstances be held liable for consequential loss or loss of profits or data. Swisscom Solutions shall not be liable for damages and the consequences of delays caused by force majeure, natural disasters (e.g. lightning, weather-related events), power outages, war, strikes, unforeseen restrictions imposed by authorities, the use of call baring, PC diallers, hacker attacks, virus attacks on data processing equipment (e.g. Trojan horses), etc. If Swisscom Solutions is unable to fulfil its contractual obligations, the performance of contract or the deadline for performance of contract will be postponed commensurate with the delay caused by the event that occurred. Swisscom Solutions shall not be liable for any damages sustained by the customer as a consequence of the contract performance being postponed.

9.9 Limitations of liability

The subscriber has exclusive liability for using the secret key on which the certificate is based.

The subscriber is liable to Swisscom Solutions for damages it may incur on account of the subscriber failing to meet its contractual obligations (in particular regarding the use of the certificate).

9.10 Term and termination

9.10.1 Term

This CP and the associated CPS [8] enter into force on the day they are published by the information service (see section 2.2) of Swisscom Digital Certificate Services.


Version 1.2 31/32

9.10.2 Termination

This document remains in effect until

• it is replaced by a newer version or

• the operations of the CA of Swisscom Digital Certificate Services are terminated.

9.10.3 Effects of termination

In the event of the CP and associated CPS [8] being terminated, the responsibility to protect confidential information and personal data and any other related obligations of the parties shall remain unchanged.

9.11 Individual notices and communication with participants

The CA communicates with the subscriber via signed e-mail, if the e-mail address is known, or letter.

Correspondence with participants takes place by means of signed forms via e-mail or letter. Announcements and news are published on the Swisscom Solutions homepage.

9.12 Policy amendments

Minor changes with no or only minimum effect for users are entered into force directly by Swisscom Solutions. Major changes are implemented by arrangement with and approval of the certification authority.

Changes are entered into a journal. All users shall be notified of major changes via e-mail 30 days before entry into force, provided their e-mail address is known. In addition, amendments shall be published in accordance with 2.2.

A formal approval procedure exists for the CP and any amendments made to it.

9.13 Dispute resolution provisions

All disputes arising out of the present CP in which Swisscom Solutions is involved shall be referred to an arbitration court in Bern for final resolution, in accordance with the provisions of the Concordat on Arbitration. The arbitration court shall be appointed by the President of the Chamber of Commerce of the Canton of Bern. The arbitration court procedure shall be in accordance with the Civil Procedure Ordinance of the Canton of Bern, unless the Concordat on Arbitration is enforced. Arbitration proceedings shall take place in German. However, the contracting partners shall undertake to make all reasonable efforts to settle their dispute amicably before appealing to the arbitration court. They can do this by enlisting the services of a joint mediator. Such an attempt at mediation will have no effect on the statutory period of limitation.

9.14 Applicable law and place of jurisdiction

The Swisscom Digital Certificate Services CP is subject to Swiss law, in particular the Swiss Signatures Act ZertES [1]. The sole place of jurisdiction is Bern.


Version 1.2 32/32

9.15 Compliance with applicable law

Swisscom Solutions reserves the right to operate as a CA in terms of the Swiss Signatures Act [ZertES] and to issue qualified certificates. Certificates are issued which allow qualified electronic signatures to be generated in accordance with the Swiss Signatures Act. In accordance with article 14, section 2 of the Swiss Code of Obligations, such signatures have equal legal validity as a hand-written signature.

In addition, the service:

• meets the requirements of the technical and administrative implementation provisions TAV [3]

• complies with the standards referred to, in particular the ETSI TS 101 456 [5] “Policy requirements for certification authorities issuing qualified certificates”

• is a “QCP public + SSCD” (a certificate policy for qualified certificates issued to the public, requiring use of secure signature-creation devices; sec. 5.2 a) of ETSI TS 101 456 [5]

9.16 Other provisions

9.16.1 Scope and applicability

All regulations contained in the CP and CPS [8] apply between the CA of Swisscom Digital Certificate Services and its subscribers for the certificates based on this CP. The release of a new version replaces all previous versions. Oral agreements or sub-agreements are not permitted.

9.16.2 Assignment of rights and obligations

The subscriber is not permitted to transfer his rights and obligations. Swisscom Solutions is entitled to transfer its rights and obligations to third parties, in particular to other Swisscom Group companies.