swiss government pki - root ca i · swiss government root ca i cp/cps v1.0 1/59 efd /...

Swiss Government Root CA I CP/CPS V1.0

1/59

EFD / Swiss_Government_Root_CA_I_CP_CPS_EN_v21.docx

Swiss Government PKI - Root CA I

Certificate Policy and Certification Practice Statement of the Swiss Gov-ernment Root CA I

Document OID : 2.16.756.1.17.3.1.0

Project Name: Swiss Government Root CA I Project Number: - Version: V2.1 Status At Work Verify Approved

Involved Persons Authors: Jürgen Weber, Jürg Spörndli, Pascal Joye, Karolina

Kohout Approval: Swiss Government PKI Responsible User: Subscribers, Swiss Government PKI Employees, Audi-

tors, Third Parties For information / knowledge: -

2/59


Changes Date Version Who Description 2011/08/17 0.1 J. Spörndli 1st Draft, chapter 1-3 2011/08/24 0.1b J. Spörndli Updates on 1-3, chapter 4 added 2011/08/31 0.1c J. Spörndli Chapters 5-9 added 2011/09/19 0.1d J. Spörndli Updates based on feedback R.Dietschi, Document

reference added 2011/10/20 0.1e J. Spörndli Updates per reviews R. Dietschi and P. Joye/D. Mark-

walder, Glossary expanded 2011/11/30 0.1f J. Spörndli Updates based on findings from CP/CPS for Root CA II

document 2011/12/30 0.2 D. Markwalder Updates and precisions 2012/01/11 0.8 D. Markwalder Draft for final review after changes and review by Karo-

lina Kohout (chapt. 8 & 9) 2012/01/18 0.9 D. Stich Grammar and consistency check 2012/01/20 1.0 D. Markwalder Approval 2012/09/05 1.1 J. Spörndli Document enhanced to reflect issuance of role certifi-

cates 2012/09/29 1.2 J. Spörndli Updated per review R. Dietschi and J. Weber 2012/12/20 2.0 J. Weber Approved 2013/03/06 2.1 J. Weber Updates and precisions

3/59


Table of Contents

1 Introduction ............................................................................................................ 81.1 Overview ............................................................................................................. 81.2 Document name and identification ....................................................................... 91.3 PKI participants ................................................................................................. 101.3.1 Certification authorities .................................................................................. 101.3.2 Registration authorities ................................................................................. 111.3.3 Subscribers ................................................................................................... 121.3.4 Relying parties .............................................................................................. 121.3.5 Other participants .......................................................................................... 121.4 Certificate Usage ............................................................................................... 131.4.1 Appropriate certificate uses ........................................................................... 131.4.2 Prohibited certificate uses ............................................................................. 141.5 Policy administration .......................................................................................... 141.5.1 Organization administering the document ..................................................... 141.5.2 Contact person .............................................................................................. 141.5.3 Person determining CPS suitability for the policy .......................................... 141.5.4 CPS approval procedures ............................................................................. 141.6 Definitions and acronyms ................................................................................... 14

2 Publication and Repository Responsibilities ..................................................... 172.1 Repositories ...................................................................................................... 172.2 Publication of certification information ................................................................ 172.3 Time or frequency of publication ........................................................................ 172.4 Access controls on repositories ......................................................................... 17

3 Identification and Authentication ........................................................................ 183.1 Naming .............................................................................................................. 183.1.1 Types of names ............................................................................................ 183.1.2 Need for names to be meaningful ................................................................. 183.1.3 Anonymity or pseudonymity of subscribers ................................................... 183.1.4 Rules for interpreting various name forms ..................................................... 193.1.5 Uniqueness of names ................................................................................... 193.1.6 Recognition, authentication, and role of trademarks ...................................... 193.2 Initial identity validation ...................................................................................... 193.2.1 Method to prove possession of private key ................................................... 193.2.2 Authentication of organization identity ........................................................... 203.2.3 Authentication of individual identity ............................................................... 203.2.4 Non-verified subscriber information ............................................................... 213.2.5 Validation of authority .................................................................................... 213.2.6 Criteria for interoperation ............................................................................... 213.3 Identification and authentication for re-key requests .......................................... 213.3.1 Identification and authentication for routine re-key ........................................ 213.3.2 Identification and authentication for re-key after revocation ........................... 213.4 Identification and authentication for revocation request ..................................... 21

4 Certificate Life-Cycle Operational Requirements .............................................. 234.1 Certificate application ........................................................................................ 234.1.1 Who can submit a certificate application ....................................................... 234.1.2 Enrollment process and responsibilities ........................................................ 234.2 Certificate application processing ...................................................................... 254.2.1 Performing identification and authentication functions ................................... 254.2.2 Approval or rejection of certificate applications .............................................. 254.2.3 Time to process certificate applications ......................................................... 254.3 Certificate issuance ........................................................................................... 264.3.1 CA actions during certificate issuance ........................................................... 26

4/59


4.3.2 Notification to subscriber by the CA of issuance of certificate ........................ 264.4 Certificate acceptance ....................................................................................... 264.4.1 Conduct constituting certificate acceptance .................................................. 264.4.2 Publication of the certificate by the CA .......................................................... 264.4.3 Notification of certificate issuance by the CA to other entities ........................ 264.5 Key pair and certificate security rules ................................................................ 264.5.1 Subscriber private key and certificate usage ................................................. 264.5.2 Relying party public key and certificate usage ............................................... 274.6 Certificate renewal ............................................................................................. 274.7 Certificate re-key ............................................................................................... 274.7.1 Circumstance for certificate re-key ................................................................ 274.7.2 Who may request certification of a new public key ........................................ 274.7.3 Processing certificate re-keying requests ...................................................... 284.7.4 Notification of new certificate issuance to subscriber ..................................... 284.7.5 Conduct constituting acceptance of a re-keyed certificate ............................. 284.7.6 Publication of the re-keyed certificate by the CA ........................................... 284.7.7 Notification of certificate issuance by the CA to other entities ........................ 284.8 Certificate modification ...................................................................................... 284.9 Certificate revocation and suspension ............................................................... 294.9.1 Circumstances for revocation ........................................................................ 294.9.2 Who can request revocation .......................................................................... 294.9.3 Procedure for revocation request .................................................................. 294.9.4 Revocation request grace period ................................................................... 304.9.5 Time within which CA must process the revocation request .......................... 304.9.6 Revocation checking requirement for relying parties ..................................... 304.9.7 CRL issuance frequency ............................................................................... 304.9.8 Maximum latency for CRLs ........................................................................... 304.9.9 On-line revocation/status checking availability .............................................. 304.9.10 On-line revocation checking requirements .................................................... 304.9.11 Other forms of revocation advertisements available ...................................... 314.9.12 Special requirements re-key compromise ..................................................... 314.9.13 Circumstances for suspension ...................................................................... 314.9.14 Who can request suspension ........................................................................ 314.9.15 Procedure for suspension request ................................................................. 314.9.16 Limits on suspension period .......................................................................... 314.10 Certificate status services .................................................................................. 314.10.1 Operational characteristics ............................................................................ 314.10.2 Service availability ......................................................................................... 314.10.3 Optional features ........................................................................................... 314.11 End of subscription ............................................................................................ 324.12 Key escrow and recovery ................................................................................... 324.12.1 Key escrow and recovery policy and practices .............................................. 324.12.2 Session key encapsulation and recovery policy and practices ...................... 32

5 Management, Operational, and Physical Controls ............................................. 335.1 Physical Controls ............................................................................................... 335.1.1 Site location and construction ....................................................................... 335.1.2 Physical access ............................................................................................ 335.1.3 Power and air conditioning ............................................................................ 335.1.4 Water exposures ........................................................................................... 335.1.5 Fire prevention and protection ....................................................................... 335.1.6 Media storage ............................................................................................... 335.1.7 Waste disposal .............................................................................................. 345.1.8 Off-site backup .............................................................................................. 345.2 Procedural Controls and System Access Management ..................................... 345.2.1 Trusted roles ................................................................................................. 345.2.2 Number of persons required per task ............................................................ 355.2.3 Identification and authentication for each role ............................................... 36

5/59


5.2.4 Roles requiring separation of duties .............................................................. 365.3 Personnel Controls ............................................................................................ 365.3.1 Qualifications, experience and clearance requirements ................................ 365.3.2 Background check procedures ...................................................................... 365.3.3 Training requirements ................................................................................... 365.3.4 Retraining frequency and requirements ......................................................... 375.3.5 Job rotation frequency and sequence ........................................................... 375.3.6 Sanctions for unauthorized actions ............................................................... 375.3.7 Independent contractor requirements ............................................................ 375.3.8 Documentation supplied to personnel ........................................................... 375.4 Audit Logging Procedures .................................................................................. 375.4.1 Types of events recorded .............................................................................. 375.4.2 Frequency of processing log ......................................................................... 385.4.3 Retention period for audit log ........................................................................ 385.4.4 Protection of audit log ................................................................................... 385.4.5 Audit log backup procedures ......................................................................... 385.4.6 Audit collection system .................................................................................. 385.4.7 Notification to event-causing subject ............................................................. 385.4.8 Vulnerability assessments ............................................................................. 385.5 Records Archival Procedures ............................................................................ 385.5.1 Types of records archived ............................................................................. 385.5.2 Retention period for archive .......................................................................... 395.5.3 Protection of archive ..................................................................................... 395.5.4 Archive backup procedures ........................................................................... 395.5.5 Requirements for time-stamping of records ................................................... 395.5.6 Procedures to obtain and verify archive information ...................................... 395.5.7 Archive collection system .............................................................................. 395.6 Key Changeover ................................................................................................ 395.7 Compromise and Disaster Recovery ................................................................. 405.7.1 Incident and compromise handling procedures ............................................. 405.7.2 Computer resources, software and/or data are corrupted .............................. 405.7.3 Entity private key compromise procedures .................................................... 405.7.4 Business continuity capabilities after a disaster ............................................. 405.8 CA or RA termination ......................................................................................... 415.8.1 Termination of Swiss Government PKI .......................................................... 415.8.2 Termination of a LRA .................................................................................... 41

6 Technical Security Controls ................................................................................ 426.1 Key pair generation and installation ................................................................... 426.1.1 Key pair generation ....................................................................................... 426.1.2 Private key delivery to subscriber .................................................................. 426.1.3 Public key delivery to certificate issuer .......................................................... 426.1.4 CA public key delivery to relying parties ........................................................ 426.1.5 Key sizes ...................................................................................................... 436.1.6 Public key parameters generation and quality checking ................................ 436.1.7 Key usage purposes ..................................................................................... 436.2 Private key protection and cryptographic module engineering controls .............. 436.2.1 Cryptographic module standards and controls .............................................. 436.2.2 Private key (n out of m) multi-person control ................................................. 436.2.3 Private key escrow ........................................................................................ 436.2.4 Private key backup ........................................................................................ 446.2.5 Private key archival ....................................................................................... 446.2.6 Private key transfer into or from a cryptographic module ............................... 446.2.7 Private key storage on cryptographic module ................................................ 446.2.8 Method of activating private key .................................................................... 446.2.9 Method of deactivating private key ................................................................ 446.2.10 Method of destroying private key ................................................................... 456.2.11 Cryptographic module rating ......................................................................... 45

6/59


6.3 Other aspects of key pair management ............................................................. 456.3.1 Public key archival ........................................................................................ 456.3.2 Certificate operational periods and key pair usage period ............................. 456.4 Activation data ................................................................................................... 456.4.1 Activation data generation and installation .................................................... 456.4.2 Activation data protection .............................................................................. 466.4.3 Other aspects of activation data .................................................................... 466.5 Computer security controls ................................................................................ 466.5.1 Specific computer security technical requirements ........................................ 466.5.2 Computer security rating ............................................................................... 466.6 Life cycle technical controls ............................................................................... 476.6.1 System development control ......................................................................... 476.6.2 Security management controls ...................................................................... 476.6.3 Life cycle security controls ............................................................................ 476.7 Network security controls ................................................................................... 476.8 Time-stamping ................................................................................................... 47

7 Certificate, CRL and OCSP Profiles .................................................................... 487.1 Certificate profile ................................................................................................ 487.1.1 Version number(s) ......................................................................................... 487.1.2 Certificate extensions .................................................................................... 487.1.3 Algorithm object identifiers ............................................................................ 497.1.4 Name forms .................................................................................................. 497.1.5 Name constraints .......................................................................................... 507.1.6 Certificate policy object identifier ................................................................... 507.1.7 Usage of policy constraints extension ........................................................... 507.1.8 Policy qualifiers syntax and semantics .......................................................... 507.1.9 Processing semantics for the critical certificate policies extension ................ 507.2 CRL profile ........................................................................................................ 507.2.1 Version number(s) ......................................................................................... 507.2.2 CRL and CRL entry extensions ..................................................................... 507.3 OCSP profile ...................................................................................................... 51

8 Compliance Audit and other Assessments ........................................................ 528.1 Frequency or circumstances of assessment ...................................................... 528.1.1 Assessment of qualified CAs ......................................................................... 528.1.2 General Audits .............................................................................................. 528.2 Identity/qualifications of assessor ...................................................................... 528.3 Assessor’s relationship to assessed entity ......................................................... 528.4 Topics covered by assessment .......................................................................... 528.5 Actions taken as a result of deficiency ............................................................... 528.6 Communication of results .................................................................................. 53

9 Other Business and Legal Matters ...................................................................... 549.1 Fees .................................................................................................................. 549.2 Financial responsibility ....................................................................................... 549.2.1 Insurance coverage ....................................................................................... 549.2.2 Other assets .................................................................................................. 549.2.3 Insurance or warranty coverage for end-entities ............................................ 549.3 Confidentiality of business information ............................................................... 549.3.1 Scope of confidential information .................................................................. 549.3.2 Information not within the scope of confidential information ........................... 559.3.3 Responsibility to protect confidential information ........................................... 559.4 Privacy of personal information .......................................................................... 559.5 Intellectual property rights .................................................................................. 559.6 Representations and warranties ........................................................................ 559.6.1 CA representations and warranties ............................................................... 559.6.2 RA representations and warranties ............................................................... 569.6.3 Subscriber representations and warranties ................................................... 56

7/59


9.6.4 Relying party representations and warranties ................................................ 569.6.5 Representations and warranties of other participants .................................... 569.7 Disclaimers of warranties ................................................................................... 569.8 Limitations of liability .......................................................................................... 569.8.1 Swiss Government PKI limitation of liability ................................................... 569.8.2 LRA limitation of liability ................................................................................ 579.8.3 Subscriber limitation of liability ...................................................................... 579.9 Indemnities ........................................................................................................ 579.10 Term and termination ......................................................................................... 579.10.1 Term ............................................................................................................. 579.10.2 Termination ................................................................................................... 579.10.3 Effect of termination and survival .................................................................. 579.11 Individual notices and communications with participants ................................... 589.12 Amendments ..................................................................................................... 589.13 Dispute resolution provisions ............................................................................. 589.14 Governing law .................................................................................................... 589.15 Compliance with applicable law ......................................................................... 589.16 Miscellaneous provisions ................................................................................... 589.17 Other provisions ................................................................................................ 589.17.1 Legally binding version of CP/CPS ................................................................ 58

10 Annexes ................................................................................................................ 5910.1 Annex A – References ....................................................................................... 59

8/59


1 Introduction

1.1 Overview

Swiss Government PKI operates a specific public key infrastructure on behalf of the Swiss government to enable certificate based authentication, data integrity and confidentiality pro-tection in the administration’s IT networks as well as its electronic document exchange. The service is primarily available for the users of the federal, cantonal and communal administra-tions, but is also extended to external users having a need for securing the document ex-change with administrative bodies.

The PKI comprises two different two-level hierarchies of CAs to cater for the many different needs:

− A group of CAs responsible for qualified and enhanced certificates, i.e. issuing qualified and enhanced certificates according to the federal administrations’ terminology (see: http://www.bit.admin.ch/adminpki/00247/index.html?lang=de). Qualified and enhanced certificates are issued on hard-tokens exclusively.

− A group of CAs supporting certificates at a lower security level (regular) for persons, organizations/organizational units and servers etc. These certificates are usually issued as soft-tokens.

The current document concentrates on the first group, i.e. CAs supporting qualified and en-hanced certificates. These CAs are:

Figure 1.1 - CA hierarchy ‘Swiss Government Root CA I’

Swiss Government Root CA I operating at first – root – level acts as the common trust refer-ence for all qualified and enhanced CAs and end-user certificates. It issues CA certificates to the CAs operating at second level exclusively, while these CAs in turn issue certificates to the end-user. The two-level CA-hierarchy enables Swiss Government PKI to easily add addi-tional second level CAs to an existing Root CA when needed and thus avoid the comparably

http://www.bit.admin.ch/adminpki/00247/index.html?lang=de�

9/59


large effort to establish new Root CAs among all interested parties (requires incorporation of Root CA certificate in all relevant browsers, installation by trusted personnel, etc.).

Now, as the above CAs all comply with the identical security requirements this particular document serves two purposes

− It details the policies governing and practices followed by the Root CA’s issuance of CA certificates for the subordinated CAs, i.e. it is certificate policy [CP] and certificate prac-tices statement [CPS] for the Swiss Government Root CA I.

− It details also the policies and practices of the subordinated CAs, i.e. it serves as CP and CPS for the CAs issuing qualified and enhanced certificates to end-users as well. Passages referring to qualified certificates exclusively are printed in red, the ones refer-ring to enhanced certificates exclusively are printed in green.

The document is structured according to RFC 3647 ‘Certificate Policy and Certification Prac-tices Framework’, chapter 6.

1.2 Document name and identification

This document is entitled ‘Certificate Policy and Practice Statement of the Swiss Government Root CA I’ and is identified by OID 2.16.756.1.17.3.1.0 .

This document is entitled ‘Certificate Policy and Practice Statement of the Swiss Government Root CA I’ and is identified the object identifier (OID) 2.16.756.1.17.3.1.0 whose components have the meaning given in Table 1.

OID Component Meaning of OID Component 2 joint-iso-itu-t 16 country 756 ch 1 organization1

17

Bundesamt für Informatik und Telekommunikation 3 AdminPKI 1 Swiss Government Root CA I 0 CP/CPS

Table 1: CP-OID of Swiss Government Root CA I

1 Allocated by the Federal Office of Communications (OFCOM)

10/59


1.3 PKI participants

Figure 1.2 – Overview of PKI participants

1.3.1 Certification authorities

Swiss Government Root CA I Swiss Government Root CA I is the first level CA constituting the basis of trust for all quali-fied and enhanced certificates. Its Root CA key and certificate have been generated on 12th February 2010 and minutes have been taken [ref. 1]. The Root CA certificate is formally dis-tributed as ‘trust anchor’ to all participants in the Swiss administration.

Swiss Government Root CA I’s tasks are:

− Ensure adherence to the processes defined for registration, certificate issuance, certifi-cate revocation and distribution of status information by all parties concerned.

− Validate requests for the issuance, re-key and revocation of second level CA certifi-cates.

− Issue initial and renewed second level CA certificates as requested.

− Revoke CA certificates where necessary.

− Generate and publish ARLs to support validation of CA certificates at all times.

11/59


− Publish/distribute the Root CA certificate fingerprint, thereby enabling interested parties to manually validate the Root CA certificate – Root CA certificates are self-signed and thus cannot be chained back to any other reference for electronic validation.

Swiss Government Root CA I is operated by Swiss Government PKI staff appointed to the task, under the responsibility of the PKI Manager.

Swiss Government second level CAs There are three second level CAs subordinated to Swiss Government Root CA I, all of them issuing end-user certificates exclusively:

− Swiss Government Qualified CA 01 issuing qualified certificates. These certificates meet the requirements laid down in the Swiss federal law on electronic signatures, ZertES [ref. 2].

− Swiss Government Enhanced CA 01 issuing enhanced certificates for signing, for au-thentication and for encryption. There are two types of authentication certificates issued by the CA: General authentication certificates used exclusively for proving certificates holders’ identities and ‘role certificates’ used for proving certificate holders have been assigned a particular role.

− Swiss Government Enhanced CA 02 issuing enhanced certificates for authentication.

The tasks of these second level CAs are:

− Ensure adherence to the processes defined for registration, certificate issuance, certifi-cate revocation and distribution of status information by all parties concerned.

− Validate requests for the issuance, re-key and revocation of end-user certificates.

− Issue initial and renewed end-user certificates as requested.

− Revoke end-user certificates on user-request or in case they are misused.

− Generate and publish CRLs to support validation of end-user certificates at all times.

The Swiss government second level CAs are operated by Swiss Government PKI staff ap-pointed to the task, under the responsibility of the PKI Manager.

1.3.2 Registration authorities

Registration of certificate applicants is done by local registration authorities (LRAs). These are units of the federal, cantonal or communal administrations trained for the particular func-tion in the issuance and maintenance of end-user certificates. They operate on the basis of a frame contract and a service level agreement (SLA) stipulated with Swiss Government PKI. LRA’s tasks are:

− Inform certificate applicants on their rights and duties.

− ‘Register’ applicants once these have submitted formal requests, i.e. verify their identi-ties and link these with the public keys to be certified.

− Verify role in Admin-Directory with requests for role certificates.

− Verify and approve certificate requests (RIO process).

− Signal applicants that their certificates have been issued and published to the Admin-Directory.

− Verify and approve re-key requests.

− Initiate or verify and approve revocation requests.

− Approve or carry out unblocking of certificate tokens (by resetting PINs). Tokens with

12/59


qualified certificates must be unblocked jointly with the respective holder (see 1.3.3).

− Approve or carry out requests for key recovery (encryption)

1.3.3 Subscribers

Subscribers are natural persons holding qualified or enhanced certificates issued on hard tokens by one of the Swiss Government PKI CAs. These subscribers are

− members of units within the federal or cantonal or communal administrations,

or

− representatives of companies having a need for exchanging electronically signed doc-uments, for certificate based authentication or for en-/decrypting documents in the con-text of their collaboration with one/several of the administration’s units2

All subscribers are required to use their keys/certificates in conformance with the law on the organization of government and administration [ref. 3] as well as the regulation on organiza-tion of the Federal Department of Finances FDF [ref. 4], and always within the framework of the respective applications (see section 1.4).

.

When requesting certificates subscribers are ‘applicants’. In the context of X.509 certificates they are ‘subjects’ and, once they’ve received the issued certificates, they are ‘holders’ of certificates.

1.3.4 Relying parties

Relying parties are

− all subscribers, i.e. owners of end-user certificates issued by any of the second level CAs,

− third parties having to verify digital signatures , authenticate remote users or encrypt messages on the basis of the certificates issued and, consequently, validate the certifi-cates.

The applications used for verifying signatures/validating certificate chains must adhere to the procedures as defined in ITU-T recommendation X.509.

1.3.5 Other participants

The Federal Office of Communications OFCOM http://www.bakom.admin.ch/ specifies the technical and administrative requirements for certification services supporting electronic sig-natures (RS 943.032.1).

The Swiss Accreditation Service SAS http://www.seco.admin.ch/sas/ identifies organizations responsible for verifying and attesting PKI provider’s compliance with the electronic signature laws.

The formal ‘Certification Body’ for issuers of qualified certificates accredited by SAS. 2 The administrative unit concerned is required to confirm these subscribers’ eligibility for getting issued Swiss Government PKI certificates.

http://www.bakom.admin.ch/�

http://www.seco.admin.ch/sas/�

13/59


SuisseID http://www.suisseid.ch/, an initiative of Federal State Secretariat for Economic Af-fairs (SECO) supporting standardized products for secure electronic authentication.

1.4 Certificate Usage

1.4.1 Appropriate certificate uses

The usage of keys certified by Swiss Government Root CA I or one of its subordinated CAs is restricted as per the following table:

Entity Private key usage Certificate usage

Swiss Government root CA I

Sign certificates for subordi-nated certification authorities

Sign ARLs (Authority Revoca-tion List)

Validate end-user certificates chaining back to Swiss Gov-ernment Root CA I

Swiss Government Qualified CA 01

Sign qualified certificates for end-users

Sign CRLs (certificate Revo-cation List)

Validate end-user certificates issued by the CA

Swiss Government Enhanced CA 01

Sign enhanced certificates for end-users

Sign role certificates for end-users



Swiss Government Enhanced CA 02

Sign enhanced certificates for end-users



Subscriber Qualified certificates: sign documents requiring formal signatures

Enhanced certificates: sign, authenticate or decrypt docu-ments/data depending on type of certificate

Use other subscribers’ public keys for encrypting docu-ments/data

Relying Party not applicable Verify electronic signatures Verify authenticity of certificate

holder Verify role of certificate holder Use subscribers’ public keys

for encrypting documents/data Table 1.1 – Authorized usage of private keys and certificates

End-user certificates issued by Swiss Government PKI as well as the corresponding keys may be used exclusively in conjunction with applications appropriate for the purpose. With qualified certificates these are applications certified to be compliant with ZertES (see [2], ar-ticle 6) and/or with one of the laws originating from directive 1999/93/EC on a community framework for electronic signatures [ref. 5].

http://www.suisseid.ch/�

14/59


1.4.2 Prohibited certificate uses

Qualified certificates Subscribers must not use their keys certified by Swiss Government PKI for any other pur-pose than electronically signing documents or other data sets.

Enhanced certificates Swiss Government PKI issues specific enhanced certificates for signing, for authenticating and for encryption. Subscribers must not use their keys certified by Swiss Government PKI for any other purpose than the one specified within the respective certificates.

1.5 Policy administration

1.5.1 Organization administering the document

The Federal Office of Information Technology, Systems and Telecommunication FOITT is responsible for administering and publishing the current CP/CPS (see also section 9.12 of this document).

1.5.2 Contact person

Contact person is the PKI Manager:

Federal Office of Information Technology, Systems and Telecommunication FOITT PKI Manager BFK 74, Monbijoustrasse 3003 Bern

1.5.3 Person determining CPS suitability for the policy

The PKI Manager and the PKI Security Officer jointly determine the document’s suitability for the purposes of the accepted policies.

1.5.4 CPS approval procedures

See section 9.12 of this document.

1.6 Definitions and acronyms

Term / Acronym Full text Explanation

ARL Authority Revocation List A list of revoked Certification Authority certificates.

CA Certification Authority An entity that issues certificates.

CP Certificate Policy A named set of rules that indicates the applicability of a certificate to a particular community and/or class of applica-tion with common security requirements.

CPS Certificate Practice Statement A statement of the practices that a CA employs in issuing,

15/59



managing, revoking and renewing or re-keying certificates.

CRL Certificate Revocation List A list of revoked certificates.

DN Distinguished Name

FIPS Federal Information Processing Standards

FIPS are issued by NIST, the U.S. National Institute of Standards and Technology http://www.itl.nist.gov/fipspubs/ .

FOITT Swiss Federal Office of Informa-tion Technology, Systems and Telecommunication

www.bit.admin.ch

Hard-token A portable, user controlled, physical device (e.g. smart-card) used to store cryptographic information and possibly also perform cryptographic functions.

ITU-T International Telecommunication Union, Telecommunication Stan-dardization Sector

www.itu.int/ITU-T The ITU-T X-series recommendations cover data networks, open system communications and security.

LDAP Lightweight Directory Access Protocol

LRA Local Registration Authority

LRAO Local Registration Officer

OFCOM Federal Office of Communications The Federal Office of Communication (OFCOM) handles questions related to telecommunications and broadcasting (radio and television) www.bakom.admin.ch .

OID Object Identifier A unique numerical sequence allowing the identification of any “thing”, in particular also documents.

PIN Personal Identification Number

PKCS Public-key Cryptography Stan-dards

PKCS are specifications produced by RSA Laboratories in cooperation with secure systems developers worldwide http://www.rsa.com/rsalabs/node.asp?id=2124 .

PKI Public Key Infrastructure

Private key Data used for creating an electronic signature or data for decrypting a data message.

Public key Data used for verifying an electronic signature or data for encrypting a data message.

PUK PIN Unlock Key Key used to unlock a blocked certificate token.

RA Registration Authority An entity that establishes enrolment procedures for certifi-cate applicants, performs the identification and authentica-tion of certificate applicants, initiates or passes along revo-cation requests for certificates, and approves applications for renewing or re-keying certificates on behalf of a CA.

RFC Request For Comments Standards issued by the Internet Engineering Task Force (IETF) http://www.ietf.org/ .

RIO Registration Identification Officer The RIO acts on behalf of a Local Registration Authority Officer (LRAO). He formally identifies certificate appli-

http://www.itl.nist.gov/fipspubs/�

http://www.bit.admin.ch/�

http://www.itu.int/ITU-T�

http://www.bakom.admin.ch/�

http://www.rsa.com/rsalabs/node.asp?id=2124�

http://www.ietf.org/�

16/59



cants/subscribers and confirms their authenticity with his signature. He informs subscribers on their rights and du-ties, has them sign the leaflet ‘information for Swiss Gov-ernment PKI Clients’ and forwards the responsible LRAO all data and documents. The LRAO at the LRA-workstation approves the requests processed through RIO.

Role certificate Authentication certificate proving certificate holder has been assigned the role identified by the certificate (on top of proving his identity).

RSA Rivest-Shamir-Adleman The most widely used algorithm today supporting public key cryptography.

SHA2 Secure Hash Algorithm The algorithm used most widely today for hashing data to be digitally signed.

SLA Service Level Agreement Service contract where the PKI services are formally de-fined.

Soft-token A data object that is used to store cryptographic informa-tion and possibly also perform cryptographic functions.

Swiss Govern-ment PKI

FOITT staff responsible for and operating all PKI services provided by the Swiss Authorities.

Table 2.1 – Definitions and Acronyms

17/59


2 Publication and Repository Responsibilities

2.1 Repositories

FOITT makes information related to Swiss Government Root CA I and its subordinated CAs publicly available through Swiss Government PKI’s web site (www.pki.admin.ch) and/or the Admin-Directory, a directory service compliant with ITU-T recommendation X.500.

Admin-Directory is available from the Swiss federal administration’s Intranet or using LDAP.

The public version of Admin-Directory is accessible from the Internet using LDAP.

2.2 Publication of certification information

FOITT publishes information related to certificates issued by Swiss Government Root CA I and its subordinated certification authorities:

− The CA certificate of the Swiss Government Root CA I and its subordinated certification authorities.

− The fingerprint of the CA certificate of the Swiss Government Root CA I and its subor-dinated certification authorities.

− All publicly accessible certificates issued by the Swiss Government Root CA I and its subordinated certification authorities.

− The authority revocation list (ARL) for the Swiss Government Root CA I.

− The certificate revocation list (CRL) for the Swiss Government Root CA I and its subor-dinated certification authorities.

− The current version of the CP/CPS for the Swiss Government Root CA I and its subor-dinated certification authorities.

2.3 Time or frequency of publication

Directory services update data on certificates several times per hour and CRLs every four hours.

Swiss Government Root CA I updates its ARL at least once a year and immediately after revoking a subordinated certification authority’s certificate.

Subordinated qualified CAs update their CRLs at least every three days with a grace period of four days and maximally one hour after revoking a subscriber certificate. Subordinated enhanced CAs update their CRLs at least every seven days with a grace pe-riod of one day and maximally eight hours after revoking a subscriber certificate. New versions of documents are published as soon as they have been approved.

2.4 Access controls on repositories

The repositories are freely accessible on a read-only basis to all users having access to the respective network, i.e. Admin-Directory to all users of the intranet of the federal administra-tion and the public version of the Admin-Directory to all Internet users.

http://www.pki.admin.ch/�

18/59


3 Identification and Authentication Unless it is explicitly stated, this section concentrates on the identification and authentication of subscribers, i.e. applicants for and holders of end-user certificates. Obviously, requests for the issuance and revocation of CA and Root CA certificates must be authenticated too. How-ever, as the respective processes are all initiated by Swiss Government PKI personnel spe-cifically appointed to the tasks, the identities and roles have already been well established and the authentication can be based on existing certificates.

3.1 Naming

3.1.1 Types of names

With all certificates issued the issuer (CA) as well as the subscriber (certificate holder) are identified by a distinguished name DN. The DN is a non-empty sequence of printable charac-ters as per ITU-T recommendation X.501. It must satisfy the requirements specified in tech-nical directive on Admin-Directory by the Federal IT Steering Unit [ref. 6].

‘Standard’ subscribers are employees of the federal, a cantonal or a communal administra-tion. They are identified by their name, first name and a unique alphanumerical code gener-ated by Admin-Directory (for details see section 3.1.5). For these ‘standard’ subscribers there is normally no other identifying data provided in the certificates such as function, title, organi-zational unit. The two exceptions to this rule are:

− In case it is essential that a certificate holder’s function or other particulars are visible from the certificates they may use option ‘FreeDN’ and compose their distinguished names freely within the limits set by the above directive. They must prove all informa-tion that will be part of the certificate on the basis of a formal document.

− With role certificates the DN comprises also the certificate holder’s role assigned by his local administration.

Swiss Government Root CA I and its subordinated CAs use a standard form of DN where the fields c, o, ou, cn and, with role certificates, RoleOccupant are populated (for details see sec-tion 7.1.4).

Persons from outside the administrations are not eligible as subscribers as a standard. How-ever, administrative bodies collaborating closely with external partners may authorize excep-tions and have Swiss Government PKI certificates issued to representatives of these compa-nies. The respective subscribers are identified in the same way as standard subscribers.

3.1.2 Need for names to be meaningful

Subscriber names must be meaningful in that they either identify an employee of an adminis-trative unit or a natural person as representative of a company.

3.1.3 Anonymity or pseudonymity of subscribers

Given Swiss Government PKI’s explicit consent, subscribers using FreeDN may give a pseudonym as identifier. In that case the subscriber DN must include the term ‘PSEUDO’ in

19/59


the distinguished name.

3.1.4 Rules for interpreting various name forms

The PKI can handle only characters as defined in ITU-T recommendation T.50, the Interna-tional Reference Alphabet. DNs containing un-supported characters are thus converted to a compliant form in the certification process.

3.1.5 Uniqueness of names

Names in Swiss Government PKI qualified and enhanced certificates must be unique. Swiss Government PKI enforces this through the following procedure:

− With the request for an initial certificate Swiss Government PKI assigns to each sub-scriber a unique alphanumerical value as per technical directive which will form part of the subscribers DN. It is derived by hashing the subscriber’s name, first name and em-ployee number. With employees of cantonal or communal administrations a number identifying the canton or the community, together with the personnel number, is used as the basis for calculating the hash value. For subscribers external to the administra-tion the unique alphanumerical value is computed by Admin-Directory from the date/time they are registered in the administrative database.

− In case an applicant’s distinguished name should nonetheless duplicate the DN of an existing subscriber, the responsible registration authority contacts Swiss Government PKI to resolve the conflict.

3.1.6 Recognition, authentication, and role of trademarks

Not relevant. Swiss Government PKI qualified and enhanced certificates don’t convey any data related to trademarks.

3.2 Initial identity validation

3.2.1 Method to prove possession of private key

Qualified certificates Depending on the intended user group the keys are generated either

− inside the secure token at a local registration office in the presence of the applicant

or

− centrally in a secure location supervised by Swiss Government PKI personnel. The to-kens are distributed to the applicants only after the respective certificates have been issued and stored on the tokens as well. The established processes ensure that no-one except the intended applicants ever get access to any token and the corresponding ini-tial PIN simultaneously. All keys are deleted from the central database immediately af-ter being copied to the tokens.

Enhanced certificates Key pairs are generated in the same way like key pairs for qualified certificates. However, Decryption keys are kept centrally as a backup.

20/59


General To prove possession of private key the token generates a (technical) certificate request by signing the public key to be certified utilizing the private key stored.

The secure token ensures that the private key can never be exported.

3.2.2 Authentication of organization identity

Not applicable with certificates issued as a standard, these are not issued to judicial persons.

‘External’ Subscribers using FreeDN may identify an organization (plus organizational units etc.) by the DN. This DN is verified on a ‘four eyes’ basis in that a first LRA officer LRAO en-ters a FreeDN in the request database according the applicant’s input, while a second LRAO verifies the applicant’s entitlement to use the DN on the basis of the documents submitted.

3.2.3 Authentication of individual identity

Applicants for certificates must prove their identity by means of a valid travel document, i.e. a passport or an identity card. The link between applicant and a certain public key is estab-lished by an LRAO who either

− supervises the applicant initiating his personal token (smart card) which will then gen-erate a key pair and the certificate request if decentralized key generation is used,

or

− personally hands out to the applicant a fully personalized and sealed token (smart card), i.e. it already contains key pair and certificate (if centralized key generation is used).

To authenticate applicants for enhanced certificates there is a third process supported with the help of ‘Registration Information Officers’ RIO. There the applicant presents himself to a RIO solely for the purpose of identification/authentication. The RIO sends the registration data to a LRA for approval. Once the requested certificate has been issued, the applicant downloads it autonomously and transfers it to his personal token. Alternatively the LRA creates a personalized and sealed token. The Unseal PIN and the token must be delivered to the applicant using two independent and validated ways (e.g. deliver Unseal PIN to the ad-dress that has been validated through a trusted system and send the token to the applicant’s line manager).

After first usage (unseal the token) the system sends an E-Mail to the address in the certifi-cate instructing the certificate subscriber to immediately revoke the certificate if he did not unseal the token himself.

Independent of how keys and certificates are technically handled, the LRAO or RIO must:

− verify the contents of the applicants certificate request form,

− verify the applicant exists in the Swiss Government PKI directory,

− verify the applicant’s name in the directory is identical to the one in the document pre-sented.

− With applications for role certificates, the LRAO or RIO must also verify the applicant’s role is confirmed by Admin-Directory.

21/59


3.2.4 Non-verified subscriber information

The LRA verifies all data necessary for identifying an applicant and, with role certificates, his role. It doesn’t do any other verification with requests for certificates.

3.2.5 Validation of authority

With requests for standard certificates there is no validation of authority required.

With certificate requests from subscribers external to the administration, the LRA validates the authority of the applicant by consulting the administrative unit having authorized the ex-ternal partner originally.

3.2.6 Criteria for interoperation

Not applicable.

3.3 Identification and authentication for re-key requests

3.3.1 Identification and authentication for routine re-key

For re-keying qualified certificates the identical process is used as for obtaining initial certifi-cates. In particular, applicants must present and authenticate themselves in person to a local registration authority. With valid requests there are new key pairs generated and new certifi-cate tokens personalized for the applicants.

Except for role certificates, enhanced certificates which are still valid may be re-keyed with-out registration. The subscriber initiates and authenticates a re-key request on-line on the basis of a valid enhanced certificate (see 4.7.3). The ‘old’ signature and authentication keys are erased by the token after successful download of the re-keyed certificates while encryp-tion keys are kept permanently.

For re-keying role certificates the responsible LRA verifies in Admin-Directory that the appli-cants are still assigned the particular roles.

3.3.2 Identification and authentication for re-key after revocation

For certificate re-key after revocation the process as per 3.3.1, first paragraph, applies for qualified as well as for enhanced certificates.

3.4 Identification and authentication for revocation request

The detailed process for revoking certificates is documented in section 4.9.3.

Any requestor may authenticate a revocation request by:

− Presenting himself in person to a LRA.

− Sending the revocation request by registered mail to the local LRA.

22/59


− Electronically signing the revocation request with his signing key, provided the revoca-tion is not done because of a suspected or actual key compromise or of the loss/theft of the certificate token.

− Contacting FOITT’s ServiceDesk which will forward the request to an LRA for approval.

− Using the application Swiss Government PKI offers for the purpose (this last option is available for revoking qualified certificates only).

The LRA verifies the requestor’s identity and authorization on the basis of the documents he presents and the data provided in conjunction with the original certificate request.

23/59


4 Certificate Life-Cycle Operational Requirements This paragraph details all requirements for end-user certificates. For Root CA and subordi-nate CA key pairs and certificates there exist identical or more stringent requirements. How-ever, as the respective processes are strictly handled by Swiss Government PKI personnel in a secure environment they are not explicitly mentioned here, except where the results have an impact on the other participants.

4.1 Certificate application

4.1.1 Who can submit a certificate application

As a standard, every employee of the federal, a cantonal or communal administration con-formant with the law on the Organization of Government and Administration (see [3]) as well as the regulation on organization of the FDF (see [4]) may submit requests for Swiss Gov-ernment PKI qualified or enhanced certificates, provided he/she has signed the frame con-tract [ref. 7] and the subscriber agreement with Swiss Government PKI [ref. 8].

Representatives of companies working closely with one of the administrative units may re-quest Swiss Government PKI qualified or enhanced certificates as well, provided the admin-istrative units concerned formally confirm to Swiss Government PKI the certificates are ne-cessary for securing the document or data exchange with the applicants for certificates.

4.1.2 Enrollment process and responsibilities

The enrollment processes supported and the responsible parties are:

Process Description Responsible

Decentralized Key Generation

1. Applicant initiates request. Applicant

2. Applicant is identi-fied/authenticated by an LRA.

LRAO

3. Certificate token is fully perso-nalized at LRA (key pair and technical certificate request generated and uploaded to CA, certificate issued by CA, downloaded and finally written to token) in presence of the applicant.

LRAO/CA

Centralized Key Generation

1. Stage secure tokens (gener-ate key pairs) and deliver to the LRA.

Swiss Government PKI

2. Applicant or his agent initiates request.

Applicant / applicant’s agent

3. Personalization of certificate token is done centrally by Swiss Government PKI (tech-nical certificate request gener

Swiss Government PKI / CA

24/59



ated and uploaded to CA, cer-tificate issued by CA, down-loaded and finally written to token).

4. Applicant and, when issuing role certificates, applicant’s role, is / are identified / au-thenticated by an LRA officer.

LRAO

5. LRA officer hands applicant the sealed certificate token and the Unseal PIN. This must be done personally or on the basis of two independent trusted ways (e.g. line manag-er and validated post ad-dress).

LRAO

RIO Decentralized Key Generation

1. Applicant or Administrative unit initiates request on his behalf.

Administrative unit

2. Certificate token is persona-lized partially (key pair and technical certificate request generated and uploaded to CA).

Applicant

3. Applicant and, when issuing role certificates, applicant’s role, is / are identified / au-thenticated by an RIO. RIO sends proof of registration to LRA.

RIO

4. LRAO approves request of applicant registered by RIO.

LRAO

5. Certificate is issued by CA. CA

6. Applicant (at his workstation) downloads certificate from CA and writes it to his certificate token.

Applicant

RIO Centralized Key Generation

1. Applicant or Administrative unit initiates request on his behalf.

Administrative unit / Applicant

2. Applicant and, when issuing role certificates, applicant’s role, is / are identified / authen-ticated by an RIO. RIO sends proof of registration to LRA.

RIO

3. LRAO approves request of applicant registered by RIO.

LRAO

4. Certificate token is persona-lized and Certificate is issued by CA.

CA

25/59



5. LRA officer delivers applicant the sealed certificate token and the Unseal PIN. This must be done on the basis of two independent trusted ways (e.g. line manager and validated post address).

Applicant

Table 4.1 – Registration Processes and Responsibilities

4.2 Certificate application processing

4.2.1 Performing identification and authentication functions

All identification and authentication functions are done by LRAs or by RIOs. Independent of the enrollment process (see 4.1.2) the LRA or RIO authenticate applicants as follows:

− Applicants are present themselves in person at the LRAO or RIO.

− Applicants’ identities are verified on the basis of a valid ID card or a passport.

− LRAO or RIO scans the identity documents presented to be stored as evidence by the CAs concerned.

4.2.2 Approval or rejection of certificate applications

LRAs accept certificate applications provided the following requirements are met:

− There exists an entry in Admin-Directory matching the data in the request.

− The authenticated applicant’s name matches the one in the request.

− Where applicable: The administrative unit responsible for a ‘non-administrative’ appli-cant confirms applicant’s entitlement for requesting Swiss Government PKI certificates.

− The DN given in the request doesn’t duplicate any of the DNs in existing Swiss Gov-ernment PKI certificates (except the ones of the actual applicant).

− The entry in Admin-Directory confirms the applicant has truly been assigned the role identified in the request for a role certificate.

Requests that don’t meet all of the requirements are either held pending to enable amend-ments or are rejected by the LRAs in case a request is clearly invalid. If they are in doubt, LRAs consult with Swiss Government PKI.

4.2.3 Time to process certificate applications

Certificate applications are processed instantaneously once the requests have been formally approved. Consequently, certificates are issued within minutes after registration by an LRAO and within maximally three days after registration by an RIO.

26/59


4.3 Certificate issuance

4.3.1 CA actions during certificate issuance

Swiss Government PKI qualified and enhanced CAs issue certificates on-line, i.e. once a valid request has been approved by an LRA the responsible CA automatically issues the certificate asked for. Depending on the enrollment process used (see 4.1.2), the CA either downloads the certificate directly to the LRA having approved the request (to be transferred to the certificate token) or holds it pending for download until the subscriber actively retrieves it from his/her own workstation.

4.3.2 Notification to subscriber by the CA of issuance of certificate

With every certificate issued, Swiss Government PKI qualified and enhanced CAs send the respective subscriber an e-mail notification, using the e-mail address indicated in the certifi-cate.

4.4 Certificate acceptance

4.4.1 Conduct constituting certificate acceptance

Swiss Government PKI doesn’t require a formal acceptance of the certificates it issues. Cer-tificates are deemed to be accepted with the handover of the fully personalized certificate tokens or with the successful download of certificates by the applicants.

4.4.2 Publication of the certificate by the CA

As a standard, encryption certificates issued by Swiss Government PKI CAs are published in Admin-Directory, accessible to employees of the federal administration. Certificates issued to ‘non-administrative’ users are published in the public part of Admin-Directory, i.e. are access-ible to all Internet users as well (by means of LDAP).

Certificates with other purposes than encryption (i.e. certificates for signing or authentication) may be published in the same way.

4.4.3 Notification of certificate issuance by the CA to other entities

Other entities are not actively notified of certificate issuance by Swiss Government PKI quali-fied or enhanced CAs. However, the LRAs can retrieve data on certificates issued at their convenience from the CA’s reporting tool.

4.5 Key pair and certificate security rules

4.5.1 Subscriber private key and certificate usage

Subscribers must use their private keys and certificates strictly as stipulated in section 1.4. In particular, signature keys and the corresponding qualified certificates are to be used exclu-

27/59


sively for electronically signing documents and for verifying signatures.

In addition to the adherence to the key usages specified, subscribers are bound to the follow-ing rules when using their keys and certificates:

− Use approved applications only.

− Ensure they alone have access to their private keys and the certificate tokens, i.e. keep PIN and PUK strictly confidential.

− In case they suspect or know a private key has been compromised, subscribers must stop signing or authenticating immediately (depending on the certified key usage) and report the incident to an LRA or FOITT’s Service Desk.

− In case data included in certificates is no longer valid, certificate holders must revoke the certificates concerned (see 4.9) and stop using signature and authentication keys.

4.5.2 Relying party public key and certificate usage

Relying parties are allowed to use public keys and certificates solely

− by means of approved applications,

− if keys and certificates are valid and active (i.e. neither suspended nor revoked),

− for the purpose(s) indicated in the certificates.

Relying parties must validate certificate chains as per ITU-T recommendation X.509.

4.6 Certificate renewal

Certificate renewal (i.e. issuing a new certificate on the basis of the key pair certified by the original certificate) is not supported by Swiss Government PKI qualified and enhanced CAs. Certificates that must no longer be used – because they expire or their contents are no long-er adequate – are re-keyed (see 4.7).

4.7 Certificate re-key

4.7.1 Circumstance for certificate re-key

Swiss Government PKI qualified and enhanced certificates must be re-keyed (i.e. new certifi-cates are issued on the basis of new key pairs) in case

− they are about to expire,

− they have been revoked,

− their contents (typically subscriber identifying data ) are obsolete.

4.7.2 Who may request certification of a new public key

The applicants entitled to request certificate re-key are identical to the ones entitled to re-quest initial certificates as per section 4.1.1.

28/59


4.7.3 Processing certificate re-keying requests

LRAs and CAs process re-keying requests in the same way as requests for original certifi-cates (see 4.1.1 through 4.2.1). In particular, subscribers must register with an LRA in exact-ly the same way as with an initial certificate request.

Except for role certificates, enhanced certificates which are still valid may be re-keyed with-out registration (see 3.3.1). The re-key request is based either on unused key pairs that have been generated before in the initial token-staging procedure or on new key pairs generated by the existing token.

When re-keying role certificates the responsible LRA verifies the applicants are still assigned the particular roles.

4.7.4 Notification of new certificate issuance to subscriber

With every certificate re-keyed, the CAs send the respective subscriber an e-mail notification, using the e-mail address indicated in the certificate.

4.7.5 Conduct constituting acceptance of a re-keyed certificate

The conduct constituting acceptance is the same as with the issuance of initial certificates (see section 4.4.1).

4.7.6 Publication of the re-keyed certificate by the CA

Re-keyed certificates are published in the same way as certificates that are issued initially (see 4.4.2).

With the publication of a re-keyed certificate the responsible CA removes a subscriber’s ear-lier certificate issued for the same purpose from Admin-Directory.

4.7.7 Notification of certificate issuance by the CA to other entities

Cantonal and communal administrative bodies having signed the applicable frame contract and concluded the agreement with Swiss Government PKI have access to Swiss Govern-ment PKI’s reporting tool. From there they can retrieve data on re-keyed certificates.

4.8 Certificate modification

Swiss Government PKI qualified and enhanced CAs do not support certificate modification. In case a certificate’s contents are obsolete, its holder must request a re-key of the certificate and thus proceed as per section 4.7. The certificate holder must also make sure that the orig-inal certificate is revoked (see 4.9.1).

29/59


4.9 Certificate revocation and suspension

4.9.1 Circumstances for revocation

Swiss Government PKI qualified and enhanced certificates must be revoked under the fol-lowing circumstances:

− A compromise of private key or PIN/PUK of a certificate token is suspected or has ac-tually happened.

− A certificate token has been lost or stolen.

− Parts of the data in a certificate are obsolete (e.g. e-mail Address and additional data within the Option ‘FreeDN’).

− A subscriber has been unassigned the role certified by a role certificate.

− A certificate has been acquired illegitimately.

− A subscriber has been dismissed or suspended by his employer.

− The contract with a subscriber has expired.

− A subscriber or LRA personnel have violated the rules set out in this CP/CPS.

− A certificate token is defective.

− A Swiss Government PKI qualified or enhanced CA ceases its operation.

4.9.2 Who can request revocation

Requests for revoking certificates can be requested by:

− Subscribers.

− LRA personnel having done the registration for the certificate in question.

− The administrative unit employing the subscriber.

− The administrative unit having vouched for ‘external’ subscribers.

− The local administration having unassigned a subscriber’s role.

− The PKI Security Officer.

− The PKI Manager.

Certificates may also be revoked on the basis of a judicial decision. The ensuing request in writing and founded must be addressed to the PKI Manager as per 1.5.2.

4.9.3 Procedure for revocation request

The procedure for revoking Swiss Government PKI qualified and enhanced certificates is as follows:

− The actual requestor (see 4.9.2) initiates the process and authenticates with an LRA, (as detailed in 3.4) during office hours or with FOITT’s Service Desk (to forward the re-quest to an LRA) at all other times.

− The LRA verifies requestor’s entitlement for launching the request. Provided the result is positive the LRA approves the request and forwards it to the responsible CA.

− The CA processes the revocation request automatically and instantaneously. It then in-

30/59


forms LRA and certificate holder on the completed revocation.

− Finally, the LRA investigates the reasons leading to the need for revocation, e.g. why a key has been compromised, what rules the certificate holder has violated and why, etc. The LRA feeds its findings to a database run by Swiss Government PKI for the pur-pose.

4.9.4 Revocation request grace period

All parties concerned must request revocation without delay once they know there is a valid reason (see 4.9.1).

4.9.5 Time within which CA must process the revocation request

Swiss Government PKI qualified and enhanced CAs revoke certificates without delay as soon as they receive approved requests from an LRA. With every revocation the responsible CA updates its CRL and uploads it to Admin-Directory for publication.

4.9.6 Revocation checking requirement for relying parties

All relying parties must ensure they are in possession of the responsible CA’s latest CRL at the moment they verify a signature on the basis of a Swiss Government PKI certificate.

4.9.7 CRL issuance frequency

Swiss Government PKI qualified and enhanced CAs issue and publish updated CRLs at least every three days (qualified CA) or seven days (enhanced CA) as a standard. Addition-ally, whenever a certificate is revoked they update and publish the respective CRL.

Swiss Government Root CA I issues and publishes updated ARLs every year as a standard. Additionally, if a certificate of one of its subordinated CAs is revoked the Root CA updates its ARL and publishes it immediately.

4.9.8 Maximum latency for CRLs

CRLs updated by the issuing CAs are sent to and published in Admin-Directory and on the web site (see 2.1) within 24h at most.

4.9.9 On-line revocation/status checking availability

Swiss Government PKI does not offer any on-line revocation/status checking services for qualified and enhanced certificates, like e.g. an on-line certificate status protocol (OCSP).

4.9.10 On-line revocation checking requirements

Relying parties are not requested to do on-line revocation checking when validating Swiss Government PKI qualified or enhanced certificates.

31/59


4.9.11 Other forms of revocation advertisements available

Apart from the publication of CRLs in Admin-Directory and on the web site (see 2.1) there are no other forms of revocation notifications available.

4.9.12 Special requirements re-key compromise

There are no special requirements re-key compromise in addition to the ones specified in 4.7 and 4.9.3.

4.9.13 Circumstances for suspension

Swiss Government PKI doesn’t support suspension.

4.9.14 Who can request suspension


4.9.15 Procedure for suspension request


4.9.16 Limits on suspension period


4.10 Certificate status services

4.10.1 Operational characteristics

The service for verifying certificates’ status is strictly confined to the issuance and publication of CRLs by Swiss Government PKI’s qualified and enhanced CAs. The CRLs list the serial numbers of certificates issued by a given CA which have been revoked but have not expired yet. The CRLs are published both in Admin-Directory and on the web site (see 2.1).

4.10.2 Service availability

The service (retrieval of CRLs) is available for at least 99% of the time during office hours. At all other times the availability of the service is not guaranteed. However, outages are shorter than 24h in 80% of all cases.

4.10.3 Optional features

There are no optional features offered for the status service.

32/59


4.11 End of subscription

The end of subscription is specified in the frame contract agreed between subscribers and Swiss Government PKI.

4.12 Key escrow and recovery

The Swiss federal law on electronic signatures ZertES (see [2]) explicitly prohibits the es-crowing of signature keys of qualified certificates.

To achieve maximum protection also for signature and authentication keys with enhanced certificates these are not escrowed by Swiss Government PKI either. Instead, certificates are revoked and re-keyed as soon as an existing key pair can no longer be used, no matter if compromised or not. With encryption keys this is different – as the original private keys are required for decrypting documents/data until all data protected is no longer used, escrow is applied to all keys used for en- and decryption.

4.12.1 Key escrow and recovery policy and practices

A key archive server runs in the background as part of the registration application operated by Swiss Government PKI. In the course of the personalization of tokens for enhanced certif-icates (see 4.1.2) it stores the applicants’ en-/decryption key pairs in a secure backup data-base.

Consequently, whenever a subscriber gets his encryption certificates re-keyed, the backed up decryption keys are automatically retrieved by the key archive server and copied on to the new certificate token together with the newly generated key pairs. Subscribers are thus able to decrypt and read old encrypted data any time by means of their current certificate token.

4.12.2 Session key encapsulation and recovery policy and practices

Swiss Government PKI does not support session key encapsulation and recovery with quali-fied and enhanced keys/certificates.

33/59


5 Management, Operational, and Physical Controls

5.1 Physical Controls

5.1.1 Site location and construction

Swiss Government PKI operates its certification infrastructure in an appropriately secured location of the FOITT.

5.1.2 Physical access

Physical access to the certification infrastructure is regulated in Swiss Government PKI’s access control directive [ref. 9].

Only persons possessing a badge with the specific permissions issued by FOITT security administration can enter the secured location containing Swiss Government PKI’s IT hard-ware. Access to the location is prohibited for all other persons unless accompanied by an authorized Swiss Government PKI employee.

The secured location is protected by different security mechanisms which are regularly checked and audited.

5.1.3 Power and air conditioning

The certification infrastructure is powered through a no-break power supply which acts as power conditioner as well.

An air condition specifically run for the secured location ensures constant temperature and humidity 7x24h.

5.1.4 Water exposures

The secured location is equipped with water detectors connected to the building’s surveil-lance center.

5.1.5 Fire prevention and protection

The secured location is equipped with smoke and heat detectors connected to the building’s surveillance center.

5.1.6 Media storage

Not applicable. Data related to the certification infrastructure is backed up in specific servers exclusively (see 5.1.8).

34/59


5.1.7 Waste disposal

Swiss Government PKI personnel use the appropriate mechanisms depending on the classi-fication of the data held by media for removal, e.g. magnetic and mechanical shredders.

5.1.8 Off-site backup

Swiss Government PKI maintains a backup-site from where certification can be upheld in case of an emergency.

Swiss Government PKI uses an off-site, protected location for storing back-up data.

5.2 Procedural Controls and System Access Management

5.2.1 Trusted roles

To enable the necessary segregation of critical duties within its certification activities, Swiss Government PKI distinguishes different trusted roles. Some of these may be attributed to the same persons, provided this doesn’t violate the ‘four eyes’ rule with security critical processes (see 5.2.2).

The trusted roles are:

− PKI Director The PKI Director represents Swiss Government PKI in the FOITT directorate and is the primary responsible for Swiss Government PKI. His main tasks are reviewing and ap-proving security and certification policies as well as assuring the operation of the infra-structure.

− PKI Manager The PKI Manager is responsible for implementing Swiss Government PKI’s services. His tasks include participating in the strategic planning, maintaining relations with clients and providers and managing Swiss Government PKI personnel.

− PKI Engineer The PKI Engineer of Swiss Government PKI is responsible for the technical support and the improvement of Swiss Government PKI’s services. He has to achieve the stra-tegic goals set by the PKI officer and the PKI manager.

The PKI Engineer is also responsible for the architecture, the design and the imple-mentation of PKI techniques. He permanently observes the technical developments in the market, ensures Swiss Government PKI possesses the latest software versions and has these installed where appropriate. Finally, he sees also to the maintenance of the configuration management database CMDB and the standard on the usage of cer-tificate tokens by subscribers (A006).

− PKI Security Officer The PKI Security Officer is responsible for enforcing compliance with all legal require-ments, for the adherence to physical and functional security policies by Swiss Govern-ment PKI and its environment. He manages the physical access control to the certifica-tion platform. The security officer is the only one entitled to access and read archives

35/59


and analyze activity logs.

− Operating Team The Operating Team is responsible for the running all services delivered by Swiss Government PKI. In particular, its tasks are maintaining support contracts with suppli-ers, ensure the availability of the certification infrastructure and co-ordinate Swiss Gov-ernment PKI operational work.

The Operating Team also maintains the applications and the network supporting regis-tration, issuance and revocation for/of certificates and the other services provided by Swiss Government PKI.

− Repository Officer The Repository Officer is responsible for the operation and the availability of the reposi-tory in conformance with the respective SLA.

− Information Officer The Information Officer is responsible for the publication of information supporting sub-scribers and third parties. He is also responsible for Swiss Government PKI’s website http://www.pki.adminl.ch and answers client’s questions addressed to [email protected] .

− Auditor The Auditor is an auditing company assigned by FOITT’s legal service. It conducts re-views at regular intervals of the conformance of the services delivered by Swiss Gov-ernment PKI with this certificate policy and practice statement and Swiss Government PKI’s detailed manuals and security policy.

− LRA Officer (LRAO) The LRAO’s task is authenticating applicants requesting or revoking Swiss Govern-ment PKI certificates and personalizing certificate tokens (smart cards).

− Local Administration Local administrations administer users’ access rights in the respective IT environment. Where necessary they assign users specific roles which may then be supported by role certificates. Local administrations are thus not a part of Swiss Government PKI itself but provide the essential reference data required for role certificates.

5.2.2 Number of persons required per task

With the exception of the standard tasks performed by the Operating Team, security critical actions require two persons having different roles (see 5.2.1) to jointly execute the steps. These actions include generating, activating, deactivating, backing up and recovering as well as destroying CA keys in hardware security modules HSM, issuing, re-keying and revoking CA certificates.

The process for issuing certificates with ‘FreeDNs’ or giving access to ISIS-MTT requires two LRAOs acting in specific roles:

− FreeDN a) A first LRAO is entitled to approve the usage of ‘FreeDN’ with a given applicant and

http://www.pki.adminl.ch/�

mailto:[email protected]�

mailto:[email protected]�

36/59


to define which LRAO will approve the corresponding certificate request. b) The second LRAO – entitled by the first one – opens the applicant for ‘FreeDN’ and approves the request (after successful verification).

− ISIS-MTT a) A fist LRAO registers the entitlements of an applicant. b) A second LRAO opens the applicant entitled for ISIS-MTT access.

5.2.3 Identification and authentication for each role

Swiss Government PKI runs a tight access rights management and control for identifying and authenticating its personnel handling the certification processes based on qualified certifi-cates. The access control uses security mechanisms capable of separating the different trusted roles detailed in 5.2.1 and 5.2.2 and identifying the specific functions within a role each of the role owners actually fulfills at any time, according to the security goals specified in section 6.5.

5.2.4 Roles requiring separation of duties

The PKI Manager assigns roles to the different Swiss Government PKI employees, ensuring that no conflicts regarding the separation of duties arise, e.g. members of the Operating Team may never be PKI Security Officers and vice versa.

5.3 Personnel Controls

5.3.1 Qualifications, experience and clearance requirements

Swiss Government Root CA I and its subordinated CAs are operated by qualified and expe-rienced employees of the Swiss federal administration. They are appointed for an indefinite period of time, and normally they are assigned on a full-time basis to tasks associated with their responsibilities within the framework of the certification platform.

Each employee is personally informed by the PKI Security Officer of the extent and limits of his area of responsibility.

Each employee’s employment contract contains a special confidentiality clause.

5.3.2 Background check procedures

To get assigned a Swiss Government PKI role, Swiss Government PKI and LRA staff are subjected to a security review as per the ordinance on security checks for persons [ref. 10].

5.3.3 Training requirements

Swiss Government PKI staff must be familiar with the software, hardware and internal opera-tional workflows of the certificate infrastructure components they work with. They must un-derstand the processes they are involved in and understand the effects of all actions they take.

37/59


5.3.4 Retraining frequency and requirements

Each employee assigned a Swiss Government PKI task receives an initial training covering the PKI system operated, its organization, security policy, emergency plans, software used and the activities he’ll be tasked with.

Each Swiss Government PKI employee must complete the necessary training after each ma-jor enhancement of system, organization, tools and/or methods.

5.3.5 Job rotation frequency and sequence

There is no job rotation established.

5.3.6 Sanctions for unauthorized actions

Unauthorized actions by Swiss Government PKI staff are sanctioned as regulated by the federal act on the responsibility of the Swiss confederation, the members of its official bodies and their officers [ref. 11].

5.3.7 Independent contractor requirements

The security requirements for temporary employees or contractor’s employees are identical to the ones for Swiss Government PKI employees (see 5.3.1, 5.3.2, 5.3.3 and 5.3.4).

Contractors will not be entitled to approve certificate requests.

5.3.8 Documentation supplied to personnel

Swiss Government PKI staff has access to the entire documentation of Swiss Governments’ PKI and, in particular, to the following documents:

− Certificate Policy and Certification Practice Statement of the Swiss Government Root CA I (this document).

− Swiss Government PKI security policy [ref. 12].

− Swiss Government PKI manual on operation and organization [ref. 13].

− Manuals on the hard- and software being used by the PKI system and applications.

5.4 Audit Logging Procedures

5.4.1 Types of events recorded

All relevant events related to the issuance and maintenance of Swiss Government PKI certif-icates are logged automatically or manually (journals, e.g. for recording entries to/exits from a protected room) for checking purposes, together with date/time, type, reason for and result of action, name of requestor, name(s) of person(s) approving (where applicable).

38/59


5.4.2 Frequency of processing log

Log files are checked as part of a daily verification as per Swiss Government PKI’s operating manual ‘periodic monitoring or functions and activities’ [ref. 14].

5.4.3 Retention period for audit log

All log files are retained for at least eleven years.

5.4.4 Protection of audit log

PKI log data is signed by the certification application and stored encrypted on a dedicated server located off-site. Only PKI Security Officer, Operating Team and Auditor are authorized to access server and log files.

5.4.5 Audit log backup procedures

The log files are backed up daily as part of Swiss Government PKI’s routine backup of its host system.

5.4.6 Audit collection system

A dedicated server within Swiss Government PKI’s infrastructure collects all log files main-tained.

5.4.7 Notification to event-causing subject

The Operating Team analyzes the log files daily and notifies the security officer and the members of operations staff of critical incidents. The event-causing subject is not informed.

5.4.8 Vulnerability assessments

A dedicated application analyzes Swiss Government PKI’s certification infrastructure at least once a week, identifying vulnerabilities and potential attempts at breaching the security of the system.

The security officer is warned in case there are critical anomalies detected.

5.5 Records Archival Procedures

5.5.1 Types of records archived

Swiss Government PKI archives all relevant data and log files relating to the issuance and maintenance of certificates. In particular, these are:

− Contractual agreements with clients.

− All certificates issued for Root CA, subordinated CAs and subscribers.

39/59


− All CRLs issued.

− Requests for revocation where electronically available.

− Subscribers’ identification data together with all information supporting the registration and copies of the documents presented.

− Log files.

− Audit reports.

− Incident reports.

− Vulnerability analysis reports.

5.5.2 Retention period for archive

Swiss Government PKI retains archived data for at least eleven years.

5.5.3 Protection of archive

Archived data is stored encrypted on two servers in two separate, secured locations off-site.

Only the security officer is authorized to access the archived data in the presence of a second Swiss Government PKI staff member (four eyes rule).

5.5.4 Archive backup procedures

All data to be archived is copied simultaneously to the off-site back-up servers.

5.5.5 Requirements for time-stamping of records

Each event registered, and, subsequently archived, gets time-stamped on the basis of the central date/time reference provided by FOITT.

5.5.6 Procedures to obtain and verify archive information

Archived information can only be retrieved by the PKI Security Officer from the backup serv-ers. There aren’t any procedures in place for verifying archive information.

5.5.7 Archive collection system

A dedicated server within FOITT’s infrastructure collects all data to be archived and encrypts it for export to the external servers.

5.6 Key Changeover

With Swiss Government PKI qualified and enhanced CAs key changeover is not supported. Instead, the CAs re-key and use the new CA keys for signing end-user certificates early enough for all end-user certificates signed by the original CA keys to expire within the validity period of the issuing CA’s original certificate.

40/59


5.7 Compromise and Disaster Recovery

5.7.1 Incident and compromise handling procedures

The PKI Security Officer specifies the procedures for incident and compromise handling and informs all Swiss Government PKI staff accordingly.

5.7.2 Computer resources, software and/or data are corrupted

All active keys and certificates used by Swiss Government Root CA I and its subordinated CAs are backed up off-site in at least two security modules at all times. All data related to the issuance and maintenance of end-user certificates is backed up daily as well. Consequently, in case any of Swiss Government PKI’s vital IT resources or data are corrupted the recovery procedures enable the resumption of the full service within maximally two days.

Data on the registration and certification processes are backed up incrementally by the CAs’ databases. Consequently, only status information may have to be recovered manually in case of DB failures.

5.7.3 Entity private key compromise procedures

In case any of the CA keys should have been compromised or is suspected to be compro-mised, the Swiss Government PKI manager activates the predefined action plan. In particu-lar, this comprises the following steps:

− Inform the Swiss Accreditation Service (SAS).

− Inform all subscribers concerned.

− Revoke the CA’s certificate (by Swiss Government Root CA I) and publish an updated ARL.

− Revoke all subscribers’ certificates signed by the compromised key.

− Generate and certify a new key pair for the CA.

− Issue new certificates for the subscribers concerned.

− Inform software vendors (Microsoft, Adobe, others) supporting Swiss Government PKI CA certificates as trust anchors and provide them with the necessary updates.

If the key of Swiss Government Root CA I should have been compromised the above meas-ures are carried out for all subordinated CAs and their subscribers as well as for the Root CA itself.

5.7.4 Business continuity capabilities after a disaster

There is an emergency facility available, capable of running Swiss Government PKI’s Swiss Government Root CA I and its subordinated CAs with all necessary processes starting seven days after a disaster.

41/59


5.8 CA or RA termination

5.8.1 Termination of Swiss Government PKI

In case Swiss Government PKI decides to terminate CA operation3

All valid certificates, including Root CA and subordinated CA certificates, will be revoked and a final CRL and ARL published on FOITTs website for a minimum of eleven years. The Root CA key and the ones of the subordinated CAs inclusive of all backup copies will be de-stroyed.

, it will inform the supervi-sory authority SAS and all subscribers at least 30 days in advance before it stops the certifi-cation activities in conjunction with Swiss Government Root CA I.

The responsibility for all certification data archived (see section 5.5) will be handed over to a custodian to be identified by FOITT’s management and will be retained for at least eleven years.

5.8.2 Termination of a LRA

In case the activities of a LRA are to be terminated Swiss Government PKI updates its lists of operational LRAs accordingly and, where necessary, amends its SLA with the administrative unit responsible for the LRA. The respective registration data is archived (by the standard archival process, see 5.5) and will be retained for at least eleven years.

3 The federal authorities don’t plan to hand over their certification services to any other provider in such a situation.

42/59


6 Technical Security Controls

6.1 Key pair generation and installation

6.1.1 Key pair generation

Root CA and subordinated CA key pairs are generated in HSMs conformant to FIPS 140-1 level 4, FIPS 140-2 Level 3 .

Subscriber key pairs to be certified by qualified certificates are generated in the certificate tokens issued to the subscribers conformant to EAL4+.

Subscriber key pairs to be certified by enhanced certificates are either generated centrally in a HSM conformant to FIPS 140-1 level 4 or FIPS 140-2 Level 3 or in certificate tokens issued to the subscribers conformant to FIPS 140-2 Level 2.

6.1.2 Private key delivery to subscriber

Private keys to be certified by qualified certificates are generated (in certificate tokens) at LRAs in the presence of the respective subscribers. The tokens with keys and certificates are handed to the subscribers by LRA officers once registration and certification have been ac-complished.

Private keys to be certified by enhanced certificates are delivered to subscribers in one of the following ways:

− Generated at an LRA in requestors presence and handed over by LRA officer (see above).

− Generated and certified centrally and handed over to requestor either at an LRA after successful registration or by means of two independent trusted ways (see 4.1.2).

− Downloaded from CA by requestor and transferred to certificate token after registration by an RIO.

6.1.3 Public key delivery to certificate issuer

Requestor’s public key is delivered to the CA within the technical certificate request generat-ed by the certificate token and signed using the private key.

6.1.4 CA public key delivery to relying parties

Swiss Government PKI publishes the certificates of Swiss Government Root CA I and its subordinated CAs

− in Admin-Directory,

− on its Website http://www.pki.admin.ch .

On request FOITT’s Service Desk provides a copy of the Root CA certificate’s fingerprint for verification.

http://www.pki.admin.ch/�

43/59


6.1.5 Key sizes

Swiss Government Root CA I and its subordinated CAs all use keys of 4096 bits.

Subscribers to the subordinate CAs use keys of 2048 bits.

6.1.6 Public key parameters generation and quality checking

All CA keys are generated by HSMs conformant to FIPS 140-1 level 4 or FIPS 140-2 level 3, subscriber’s qualified keys are generated by certificate tokens conformant to EAL4+ or, with central key generation, by HSMs conformant to FIPS 140-1 level 4 or FIPS 140-2 level 3.

Keys that are used for enhanced certificates only, may be generated by certificate tokens conformant to FIPS 140-2 Level 2.

6.1.7 Key usage purposes

The key usage flags are populated in all Root CA, CA and end-user certificates issued.

Swiss Government PKI ensures Root CA and CA private keys are strictly used as indicated by the flags, i.e. for certificate and CRL signing.

Subscribers are bound by the frame contract with Swiss Government PKI to use their private keys only for the purposes indicated in the respective certificates as well.

6.2 Private key protection and cryptographic module engineering controls

6.2.1 Cryptographic module standards and controls

Swiss Government PKI CAs as well as all subscribers for qualified certificates use modules (HSMs and certificate tokens) conformant to FIPS 140-1 level 4, FIPS 140-2 Level 3 or EAL4+ (see also 6.1). Subscribers for enhanced certificates may use tokens conformant to FIPS 140-2 Level 2.

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

All activities involving Root CA or CA keys except signing certificates and CRLs require the presence of at least two authorized Swiss Government PKI staff members. In particular these are the generation, backup and recovery, activation and deactivation of the keys and the exchange of HSMs.

6.2.3 Private key escrow

Subscribers’ en-/decryption key pairs are escrowed by a key archive server run by Swiss Government PKI which encrypts the key pairs for storage. The server is operated in a secure location and accessible to specifically authorized Swiss Government PKI staff only.

44/59


6.2.4 Private key backup

Root CA and CA private keys are backed up in at least two HSMs stored in separate, secure locations off-site. For activating backup HSMs at least two appropriately authorized Swiss Government PKI staff are required.

6.2.5 Private key archival

There are no private keys archived.

6.2.6 Private key transfer into or from a cryptographic module

Root CA and subordinate CA private keys are transferred between HSMs for backup pur-poses. The transfers require two Swiss Government PKI staff authorized for the task, the keys to be transferred are encrypted.

Subscribers’ keys to be certified by qualified certificates are never transferred.

Keys intended for enhanced certificates are either

− generated in subscriber’s certificate tokens and thus never transferred as well,

− generated and written un-encrypted to certificate tokens centrally in a secure location,

−

Private keys that are used for authentication or signing certificates are never transferred other than in the secure location. Private keys that are used for encryption and need to be recovered are transferred encrypted with a transport key that has been generated by the token.

6.2.7 Private key storage on cryptographic module

Root CA and subordinated CA’s private keys are stored encrypted within the HSMs and are decrypted only when activated.

Subscribers’ keys are stored un-encrypted in the certificate tokens.

6.2.8 Method of activating private key

Root CA and subordinated CA’s private keys are activated with the launching of the certifica-tion application by the security officer. The activation process requires the presence of at least one Swiss Government PKI staff authorized for the task beside the PKI Security Officer.

Subscribers activate their certificate tokens and private keys by entering the token PIN.

6.2.9 Method of deactivating private key

Root CA and subordinated CA’s private keys are deactivated with the closure of the certifica-tion application by the security officer. The deactivation process requires two Swiss Govern-ment PKI staff members authorized for the task beside the PKI Security Officer.

Subscribers’ private keys are deactivated when the certificate tokens are powered off, i.e.

45/59


either with the removal of the tokens or the closing down of the subscribers’ workstation.

6.2.10 Method of destroying private key

Root CA and subordinated CA’s private keys are destroyed by the HSMs in that the respec-tive locations in HSMs memory are actively overwritten. The process requires at least two Swiss Government PKI staff members authorized for the task.

Subscribers’ private keys are destroyed by destroying the respective certificate tokens.

6.2.11 Cryptographic module rating

For ratings see section 6.2.1.

6.3 Other aspects of key pair management

6.3.1 Public key archival

All public keys – Root CA’s, subordinated CAs’ and subscribers’ – to be used for verification purposes are archived as integral parts of the certificates issued for at least eleven years (for details on archival see 5.5).

6.3.2 Certificate operational periods and key pair usage period

Swiss Government PKI certificate validity periods are:

− 24 years for Swiss Government Root CA I.

− 14 years for the subordinated CAs.

− a maximum of 4 years for end-user certificates.

The usage periods for the private signature keys are:

− 10 years for Swiss Government Root CA I.

− 12 years for the subordinated CAs.

− a maximum of 4 years for end-user certificates.

The usage periods for private authentication keys and for public encryption keys are not ex-plicitly limited, these expire together with the respective certificates. The public signature ve-rification keys and the private decryption keys don’t expire as they might be needed for veri-fying signatures or decrypting documents/data long after the respective certificates have ex-pired.

6.4 Activation data

6.4.1 Activation data generation and installation

Supervised by the PKI Security Officer, activation data for the HSMs storing Root CA and subordinated CA keys is generated individually by the different authorized Swiss Govern-

46/59


ment PKI staff members. The passphrases and parameters are then entered as advised by the HSM’s provider.

Activation data for the certificate tokens – PINs and PUKs – is generated and entered indivi-dually by the subscribers in the course of the token personalization. Where certificate tokens are fully personalized centrally (applies for tokens for enhanced certificates only) PIN is handed to the subscriber in a sealed envelope after successful registration.

6.4.2 Activation data protection

Swiss Government PKI staff members possessing parts of one or more HSMs’ activation data must keep this data locked at all times unless there is a HSM to be activated or deacti-vated.

Subscribers should not write down certificate token PINs. If a PIN or PUK is written down, they must be kept locked.

6.4.3 Other aspects of activation data

Activation data for HSMs must comply with the rules laid down in Swiss Government PKI’s Security Policy (see [12]).

In the course of registration the LRA officers instruct subscribers on how to adequately pro-tect access to their certificate tokens and private keys and the possible consequences of neglect in that respect.

6.5 Computer security controls

6.5.1 Specific computer security technical requirements

Swiss Government PKI uses mandatory access control with all applications making up its PKI service.

With critical processes such as re-keying CA keys, handling HSMs etc., segregation of duties is enforced, requiring typically two authorized Swiss Government PKI staff members for a process to execute.

There is a penetration test performed weekly on Swiss Government PKI’s IT infrastructure, and it is audited yearly by the Auditor (see section 8.2).

6.5.2 Computer security rating

No stipulation.

47/59


6.6 Life cycle technical controls

6.6.1 System development control

With each development of a new software component, Swiss Government PKI performs an analysis of the risks this brings about.

Swiss Government PKI operates a configuration management tool ensuring only approved and tested hard- and software is deployed. With priority Swiss Government PKI employs reli-able products protected against unauthorized changes.

6.6.2 Security management controls

The PKI Security Officer regularly verifies the integrity of the certification service’s compo-nents.

6.6.3 Life cycle security controls

No stipulation.

6.7 Network security controls

Swiss Government PKI’s certification infrastructure is operated in a specific network-segment separated from the federal administration’s intranet by a gateway acting as a firewall. This blocks all protocols which are not absolutely necessary for Swiss Government PKI’s opera-tions.

6.8 Time-stamping

Swiss Government PKI offers a time-stamping service supporting electronic signing. Swiss Government PKI operational rules apply likewise for the time-stamping service, for details see the time stamping authority’s policy [ref. 15].

48/59


7 Certificate, CRL and OCSP Profiles All certificates and CRLs issued by Swiss Government Root CA I and the subordinated quali-fied CAs conform to the technical and operational requirements specified by ZertES (see [2], article 3.4).

Certificates and CRLs issued by subordinated enhanced CAs conform to same requirements although these CAs are not covered by ZertES.

7.1 Certificate profile

Unless it is explicitly indicated, certificates issued for Swiss Government Root CA I, its sub-ordinate CAs and end-users adhere to the identical profile

7.1.1 Version number(s)

Swiss Government PKI qualified and enhanced certificates are of version 2, issued in accor-dance with recommendation X.509 v3.

7.1.2 Certificate extensions

Certificate extensions used with Swiss Government Root CA I’s and subordinate CA’s certifi-cates:

Extension Objective Criticality

Authority Key Identifier Identifies key used by issuer of certificate. not critical

Subject Key Identifier Identifies key used by subject of certificate. not critical

Key Usage Lists intended usages of private key. critical

Certificate Policies Identifies policy governing the operation of the Root CA (the current CP/CPS).

not critical

Basic Constraints 1. Indicates type of certificate subject: CA or end-user (here: CA).

2. Indicates how many CA levels may be subordinated to CA (with Root CA I: no limit given, with subordinated CAs: limit is 0).

critical

CRL Distribution Points Lists address(es) where status information on certificate may be found.

not critical

Table 7.1 – Root CA and CA certificate extensions

Certificate extensions used with end-user certificates:


Authority Key Identifier Identifies key used by issuer of certificate. not critical

Subject Key Identifier Identifies key used by subject of certificate (the end-user).

not critical

49/59



Key Usage Lists intended usages of private key. critical

Certificate Policies Identifies policy governing the operation of the Root CA (the current CP/CPS).

not critical

CRL Distribution Points Lists address(es) where status information on certificate may be found.

not critical

Table 7.2 – End-user certificate extensions

7.1.3 Algorithm object identifiers

There are two algorithms used in conjunction with Swiss Government PKI qualified and en-hanced certificates identified by an OID:

− OID 1.2.840.113549.1.1.11 identifies algorithm ‘sha256WithRSAEncryption’, the algo-rithm Swiss Government PKI uses for signing certificates throughout.

− OID 1.2.840.113549.1.1.1 identifies algorithm ‘rsaEncryption’, the algorithm to be used for verifying electronic signatures generated by Swiss Government PKI’s subscribers.

7.1.4 Name forms

Swiss Government Root CA I and the subordinated CAs are identified in the certificates (as issuer and/or subject) as follows:

DN Field Value

Country (c) CH

Organization (o) Admin

Organizational Unit (ou) Services

Organizational Unit (ou) Certification Authorities

Common Name (cn) Swiss Government <Name of individual CA> Table 7.3 – CA Name forms Subscribers are identified as certificate subjects in the following way: DN Field Value

Country (c) CH


Organizational Unit (ou) Weisse Seiten

Common Name (cn) <Lastname><Firstname><Suffix> Table 7.4 – Subscriber name forms Subscribers to role certificates are identified as subjects in the following way: DN Field Value

Country (c) CH

50/59



Organizational Unit (ou) Weisse Seiten

Common Name (cn) <Lastname><Firstname><Role>

RoleOccupant <Lastname><Firstname><Suffix> Table 7.5 – Subscriber name forms with role certificates

7.1.5 Name constraints

Name constraints are not used by Swiss Government PKI with the issuance of qualified and enhanced certificates.

7.1.6 Certificate policy object identifier

The one applicable policy OID is the one of the current document: 2.16.756.1.17.3.1.0

7.1.7 Usage of policy constraints extension

Policy constraints are not used by Swiss Government PKI with the issuance of qualified and enhanced certificates.

7.1.8 Policy qualifiers syntax and semantics

Policy qualifiers are not used by Swiss Government PKI with the issuance of qualified and enhanced certificates.

7.1.9 Processing semantics for the critical certificate policies extension

With the issuance of qualified and enhanced certificates the certificate policies extension is set to ‘not critical’, Swiss Government PKI doesn’t expect relying parties to process policy information electronically.

7.2 CRL profile

7.2.1 Version number(s)

CRLs generated by Swiss Government PKI qualified and enhanced CAs are of version 2, issued in accordance with recommendation X.509 v3.

7.2.2 CRL and CRL entry extensions

CRL and CRL entry extensions used with Swiss Government Root CA I’s and subordinate CAs’ certificates are:

CRL Extension Objective Criticality

CRL number Number of CRL (CRLs are sequentially num- not critical

51/59


CRL Extension Objective Criticality bered).

CRL Entry Extension

Reason Code Identifies actual reason for revoking certificate. not critical

Invalidity Date Indicates known or suspected date a key was compromised.

not critical

Table 7.5 – CRL and CRL entry extensions

7.3 OCSP profile

Swiss Government PKI doesn’t offer any OCSP services in conjunction with the qualified and enhanced certificates its CAs issue.

52/59


8 Compliance Audit and other Assessments

8.1 Frequency or circumstances of assessment

8.1.1 Assessment of qualified CAs

Swiss Government Root CA I together with the subordinated CAs issuing qualified certifi-cates are subject to the provisions of ZertES (see [2]). Accordingly, a recertification of Root CA and enhanced CAs is conducted yearly by the Certification Body (see 1.3.5.).

8.1.2 General Audits

Swiss Government PKI Root CA and subordinated qualified and enhanced CAs are subject to a verification of their compliance with the requirements of this CP/CPS at least yearly. These audits are done by the Auditor (see 5.2.1).

8.2 Identity/qualifications of assessor

− The Certification Body is the body formally certifying providers of qualified certification services, accredited by SAS for the task (see section 1.3.5).

− The Auditor assigned by FOITT is an independent company carrying out audits in ac-cordance with the statutory and regulatory provisions.

8.3 Assessor’s relationship to assessed entity

The audits are conducted by organizations mandated by FOITT, completely independent of the federal administration.

8.4 Topics covered by assessment

Audits on the services issuing qualified certificates verify that all respective requirements emanating from the federal laws on electronic signatures are met by Swiss Government PKI.

The audits ordered by FOITT cover Swiss Government PKI’s adherence to this CP/CPS in terms of its organization, operation, personnel training and management.

8.5 Actions taken as a result of deficiency

PKI Manager and PKI Security Officer agree with the auditing body on the necessary actions and time schedules to correct/eliminate the deficiencies identified. They’ll jointly see to the initiation and successful completion of the resulting tasks.

53/59


8.6 Communication of results

Audit results are just communicated to PKI Director, PKI Manager and PKI Security Officer as a standard and, where advisable, to other employees/units of the federal administration on a ‘need to know’ basis, e.g. Swiss Government PKI staff, FOITT legal services, etc.

54/59


9 Other Business and Legal Matters

9.1 Fees

Swiss Government PKI’s costs for running the certification services basing on Swiss Gov-ernment Root CA I and its subordinate CAs are covered by the administrative units at feder-al, cantonal or communal level employing the certificate subscribers, as agreed in the re-spective SLA.

The costs arising from operating an LRA or an RIO (registering and supporting applicants, certificate tokens, readers, etc.) are covered by the administrative units running the LRA.

Costs arising on subscriber’s side are covered by the responsible administrative unit.

9.2 Financial responsibility

9.2.1 Insurance coverage

With FOITT being part of the federal administration the Swiss Federation is responsible for the necessary insurance as per the federal regulation on certification services supporting electronic signatures VZertES, article 2 [ref. 16]. By its declaration of 1 June 2006, the FDF has confirmed it is liable for Swiss Government PKI’s certification services, thereby eliminat-ing the need for insurance (as per paragraph 2 of the article).

The LRAs must ensure they are adequately insured against damages caused by their regis-tration activities.

9.2.2 Other assets

The cantonal and communal administrations’ liability is regulated in an appendix to the SLA.

9.2.3 Insurance or warranty coverage for end-entities

Subscribers must ensure they are adequately insured against damages caused by their elec-tronically signing documents.

9.3 Confidentiality of business information

9.3.1 Scope of confidential information

The following data is regarded as confidential and treated accordingly:

− All subscriber related data which are not shown in certificates or CRLs.

− Audit logs generated with Swiss Government PKI’s operation of the certification servic-es and all data archived.

− Audit reports and any other assessment results.

55/59


9.3.2 Information not within the scope of confidential information

Explicitly not within the scope of confidential information are:

− All data on subscribers shown in certificates and CRLs are not confidential; these are usually published formally (see section 2).

− Swiss Government PKI documents intended for subscribers, relying parties and third parties, e.g. this CP/CPS.

9.3.3 Responsibility to protect confidential information

All Swiss Government PKI staff and LRAO are responsible for protecting confidential infor-mation. The PKI Security Officer specifies the respective requirements and measures and enforces these in the daily operation.

9.4 Privacy of personal information

All Swiss Government PKI staff and LRAO must observe the requirements stipulated in the Swiss laws on data protection and on electronic signatures, where applicable.

All Swiss Government PKI staff and LRAO may collect only subscriber data necessary for registration and certification and use it for these purposes exclusively. In particular, they must not use subscriber data for any commercial purposes.

9.5 Intellectual property rights

Swiss Government PKI is owner of the intellectual property rights of the following documents:

− Certificate Policy and Certification Practice Statement of Swiss Government Root CA I (this document).

− Directives for Registration for Swiss Government PKI qualified and enhanced certifi-cates.

− Contracts and other agreements concluded between Swiss Government PKI and its clients (federal, cantonal and communal administrative units).

− Qualified and enhanced certificates issued by Swiss Government PKI.

The reproduction, presentation (including publication and distribution) as a whole or in part, by any means, without Swiss Government PKI’s explicit authorization in writing obtained in advance, is strictly forbidden.

Administrative units employing subscribers or subscribers themselves do not acquire owner-ship of the certificates issued by Swiss Government PKI, they just obtain the right to used these.

9.6 Representations and warranties

9.6.1 CA representations and warranties

Swiss Government PKI is committed to provide its services for issuing qualified and en-

56/59


hanced certificates in compliance with ZertES (see [2]) and the current CP/CPS.

9.6.2 RA representations and warranties

The LRA are committed by contract to do registration in compliance with the law on electron-ic signatures ZertES (see [2]) and the current CP/CPS.

9.6.3 Subscriber representations and warranties

Subscribers commit to acquire, use and maintain their private keys, certificates and certifi-cate tokens in compliance with ZertES (see [2]) and the current CP/CPS.

9.6.4 Relying party representations and warranties

Relying parties must use certificates issued by Swiss Government PKI in accordance with ZertES (see [2]) and the current CP/CPS.

9.6.5 Representations and warranties of other participants

No stipulation.

9.7 Disclaimers of warranties

All other warranties by any of the parties identified (see section 1.3) are excluded.

9.8 Limitations of liability

9.8.1 Swiss Government PKI limitation of liability

Swiss Government PKI is liable in accordance with ZertES, article 16 (see [2]). As far as possible the liability of the Swiss Government PKI is limited to the extent permitted by appli-cable law. In particular the Swiss Government PKI is not liable for:

- all damages resulting from the usage of certificates or key pairs in any other way than defined in this document, in the Swiss Government PKI instructions or stipulated in the certificate itself,

- all damages caused by force majeure,

- all damages caused by malware (such as virus attacks, Trojans) on the clients infra-structure

For all other damages caused by the use of qualified certificates, the liability is limited to the extent permitted by applicable law:

− In case of a minor negligence the indemnity is equal to the value of Swiss Government

57/59


PKI’s services delivered in the year running, but maximally CHF 50’000.- per incident and calendar year.

− In case of a major negligence the liability cap is CHF 100’000.- per incident and calen-dar year.

9.8.2 LRA limitation of liability

The cap on LRA’s liability is specified in the contract between LRA and Swiss Government PKI, but strictly in accordance with VZertES (see [16]) as far as qualified certificates are con-cerned. In particular, the LRA is liable for the registration of subscribers and for revoking cer-tificates in case of a misuse.

9.8.3 Subscriber limitation of liability

Limitations of liability of subscribers (employees of federal, cantonal or communal administra-tions, or of private companies) are as specified in the Federal or cantonal laws on electronic signatures. In particular, the Subscriber is liable for damages caused by a breach of his due diligences (such as handling over token and PIN to somebody else or not revoking his com-promised certificate).

9.9 Indemnities

Swiss Government PKI cannot give explicit information on indemnities in addition to the statements in sections 9.6 through 9.8.

9.10 Term and termination

9.10.1 Term

This CP/CPS becomes valid the day it is published on Swiss Government PKI’s website (see section 2.2).

9.10.2 Termination

This CP/CPS is valid until

− it is replaced by a newer version, or

− Swiss Government PKI ceases its activities as issuer of qualified and enhanced certifi-cates.

9.10.3 Effect of termination and survival

Even once CP/CPS may no longer be valid, the regulations pertaining to the laws on data protection and on archival of information are still observed.

58/59


9.11 Individual notices and communications with participants

As a standard, Swiss Government PKI communicates by e-mail with all participants.

Agreements and contracts are to be exchanged in writing to become effective. Alternatively, the documents may be signed electronically and exchanged by email where applicable.

9.12 Amendments

The PKI Manager may apply minor changes to this CP/CPS (typographic corrections, revise parts of the document, etc.) autonomously and publish it without notification to the other par-ticipants.

Substantial changes to the CP/CPS must be advertised 30 days in advance and be made in agreement with the Certification Body’s security officer (see 1.3.5).

Subscribers will be notified where necessary.

9.13 Dispute resolution provisions

The dispute resolution provisions form part of the frame contract concluded between Swiss Government PKI and the subscribers.

9.14 Governing law

This CP/CPS is subject to the applicable Swiss federal laws, particularly the laws on elec-tronic signatures ZertES (see [2]) and on data protection DSG (ref. [17]). The only place of jurisdiction is Berne.

9.15 Compliance with applicable law

No stipulation.

9.16 Miscellaneous provisions

No stipulation.

9.17 Other provisions

9.17.1 Legally binding version of CP/CPS

This English version of the CP/CPS is legally binding. Versions of this CP/CPS in other lan-guages serve informational purposes only.

59/59


10 Annexes

10.1 Annex A – References

[1] Minutes of Swiss Government Root CA I root ceremony

[2] SR 943.03 Federal law on the certification services supporting electronic signatures ZertES http://www.admin.ch/ch/d/sr/c943_03.html

[3] SR 172.010 Federal law on the Organization of Government and Administration (RVOG) http://www.admin.ch/ch/d/sr/c172_010.html

[4] SR 172.215.1 Regulation on the Organization of the Federal Department of Finances (OV-EFD) http://www.admin.ch/ch/d/sr/c172_215_1.html

[5] Directive 1999/93/EC of the European Parliament and the Council of December 13, 1999, on a Community Framework for Electronic Signatures http://portal.etsi.org/esi/Documents/e-sign-directive.pdf

[6] Technical directive I006 ’Structure of the Admin-Directory’ by the Federal IT Steering Unit http://www.isb.admin.ch/themen/standards/alle/03149/index.html?lang=de

[7] Frame contract between Subscriber and Swiss Government PKI

[8] Subscriber agreement with Swiss Government PKI

[9] Swiss Government PKI access control directive

[10] Ordinance on Security Checks for Persons (OSCP)

[11] SR 170.32 Federal Act on the Responsibility of the Swiss Confederation, the Mem-bers of its Official Bodies and their Officers http://www.admin.ch/ch/d/sr/17.html#170.32

[12] Swiss Government PKI security policy

[13] Swiss Government PKI manual on operation and organization

[14] Swiss Government PKI’s operating manual ‘Periodic Monitoring or Functions and Ac-tivities’

[15] Policy of Time Stamping Authority

[16] SR 943.032 Regulation on certification services supporting electronic signatures VZertES http://www.admin.ch/ch/d/sr/c943_032.html

[17] SR 235.1 Federal law on data protection DSG http://www.admin.ch/ch/d/sr/c235_1.html

http://www.admin.ch/ch/d/sr/c943_03.html�


http://www.admin.ch/ch/d/sr/c172_215_1.html�

http://portal.etsi.org/esi/Documents/e-sign-directive.pdf�

http://www.isb.admin.ch/themen/standards/alle/03149/index.html?lang=de�

http://www.admin.ch/ch/d/sr/17.html#170.32�

