Certificate Infrastructure Certificate Practice …ca.unicreditgroup.eu/CPS/cps.pdfCertificate...

Date: 21/11/2008 Pag. 1/35

Certificate Infrastructure Certificate Practice Statement Author

Unicredit Global Information Services

Version 1.0

Attachment

Approved by: Francesco Oliva

Date: 21/11/2008 Pag. 2/35

Version updates

Rev Date Author Description

1.0 19/11/08 ICT Security

1.1 01/11/09 ICT Security Manager Change

Comments to the document

Date: 21/11/2008 Pag. 3/35

Index

1. Document objectives 7

2. Definition and shortcuts 7

3. Introduction 10

3.1. Identification 10

3.2. Entities and applicability 10

3.2.1. Certification Authority (CA) 10

3.2.2. Registration Authority (RA) 10

3.2.3. Subscriber 10

3.2.4. Applicability 10

3.3. Refer 10

3.3.1. Organization 10

3.3.2. Roles 10

4. General Conditions 11

4.1. Duties 11

4.1.1. CA Duties 11

4.1.2. RA Duties 11

4.1.3. Company Duties 11

4.1.4. Subscriber Duties 12

4.1.5. Other Entities Duties 12

4.1.6. Directory Duties 12

4.2. Warranties and Liability Limitation 12

4.2.1. CA Responsibilities 12

4.2.2. RA Responsibilities 12

4.3. Financial Responsibilities 12

4.4. Interpretation of Laws 13

4.5. Fares 13

4.6. Publishing and Repository 13

4.6.1. Information Publishing 13

4.6.2. Update Frequency 13

4.6.3. Access Control 13

4.6.4. Directory 13

4.7. Audit Process 13

4.7.1. Frequency 13

4.7.2. Controller Identity and Qualification 13

4.7.3. Relation between Collaborator and PKI 14

4.7.4. Process and System Controlled 14

Date: 21/11/2008 Pag. 4/35

4.7.5. Action to Do in Case of Malpractice 14

4.7.6. Communication of results 14

4.8. Confidentiality policy 14

4.9. Copyright 14

5. Identification and Authentication 14

5.1. Initial Registration 15

5.1.1. Usable Names 15

5.1.2. Name Meaning 15

5.1.3. Rules to Interpret Names 15

5.1.4. Uniqueness of Name 15

5.1.5. Name Conflicts Resolution 15

5.1.6. Company Property 15

5.1.7. Private Key Possession Proof 15

5.1.8. Company Organization 15

5.1.9. Entities Identification 15

5.2. Certificate Renewal Request 16

5.3. Encryption Private Key Recovery 16

5.3.1. Subscriber Request to Recover Encryption Private Key 16

5.4. Certificate Revocation Request Authentication 16

6. Management Requirement 16

6.1. Certificate Request 16

6.1.1. Internal User 16

6.2. Certificate Issuing 16

6.3. Certificate Acceptance 17

6.4. Certificate Revocation 17

6.4.1. Revocation Reasons 17

6.4.2. Entities which can Revoke a Certificate 17

6.4.3. Certificate Revocation Request Procedure 18

6.4.4. Timing to Request for a Revocation Process 18

6.4.5. CRL Frequency Issuing and Availability 18

6.5. Control Procedures 18

6.5.1. Event Logged 18

6.5.2. Log Analysis 19

6.5.3. Log Maintenance 19

6.5.4. Log Protection 19

6.5.5. Log Backup Copy 19

6.5.6. Log Storing 19

6.5.7. Notification to Subject which Caused Critical Events 19

6.5.8. Vulnerability Assessment 20

Date: 21/11/2008 Pag. 5/35

6.6. Information Stored 20

6.6.1. Information Stored Types 20

6.6.2. Archive Storing Living Range 20

6.6.3. Archive Protection 20

6.6.4. Archive Backup 20

6.6.5. Time Identification in Log File 20

6.6.6. Procedure to Verify and Obtain Information Stored 20

6.7. Keys Renewal 20

6.7.1. Subscriber Keys Renewal 20

6.7.2. CA Key Renewal 20

6.8. Emergency Procedure and Disaster Recovery 21

6.8.1. Environmental Disaster 21

6.8.2. CA Key Revocation 21

6.8.3. Hardware and Software Malfunction 21

6.9. CA Activity Cessation 21

7. Environmental, Procedural and Operational Security Policies 22

7.1. Environmental Security Policies 22

7.1.1. Building 22

7.1.2. Physical Access 22

7.1.3. Energy, Wiring and Air 23

7.1.4. Water Exposure 23

7.1.5. Fire Measurement 23

7.1.6. Storing Device 23

7.1.7. Garbage Management 23

7.1.8. Storing in other Place 23

7.2. Procedural Security 23

7.2.1. Profiles 23

7.2.2. Number of People Needed for Operations 24

7.2.3. CA Employers Recognition 24

7.3. Employers Security 24

7.3.1. Employers 24

7.3.2. Qualification and Experience 24

7.3.3. Formation 24

7.3.4. Frequency of Update 24

7.3.5. Profile Shifting 25

7.3.6. Fee for Not Authorized Operations 25

7.3.7. Documentation 25

8. Technical Security 26

8.1. Generation and Storing of the Keys 26

8.1.1. Key Generations 26

8.1.2. Releasing of Encryption Private Keys to Subscriber 26

Date: 21/11/2008 Pag. 6/35

8.1.3. Releasing of Public Keys to CA 26

8.1.4. Releasing of CA Public Key to Subscriber 26

8.1.5. Key Length 26

8.1.6. CA Key Generation 26

8.1.7. Certificate Use 26

8.2. Private Keys Protection 27

8.2.1. Enciphering Module Standard 27

8.2.2. Private Keys Management 27

8.2.3. Signature Private Key escrow 27

8.2.4. Private Key Backup 27

8.2.5. Private Key Storing 27

8.2.6. Inserting of Private Key in Cryptographic Module 27

8.2.7. Private Key Activation 27

8.2.8. Private Key Deactivation 27

8.2.9. Private Key Destruction 28

8.3. Other Management Key Aspect 28

8.3.1. Public Key Filing 28

8.3.2. Key Pair Life Cycle 28

8.4. Activation Data 28

8.4.1. Activation Data Generation and Installation 28

8.4.2. Activation Data Protection 28

8.5. Computer Security 28

8.6. Network Security 28

9. CRL and Certificate 29

9.1. Subscriber Certificate Profile 29

9.2. CRL Profile 29

10. Policy Management 30

10.1. New Practice Statements 30

10.2. CPS Update 30

10.2.1. Elements Updatable without Warning 30

10.2.2. Elements Updatable with Warning 30

10.2.3. Update Notification 30

10.2.4. Comment 30

10.2.5. Comment Management 30

10.2.6. Correction Applicability 30

11. Appendix A: Verification about Certificate Validity 31

12. Appendix B: Certificate Template 32

Date: 21/11/2008 Pag. 7/35

1. Document objectives This document aims to describe non confidential operative procedures, applied at UGIS PKI in order to issue certificate. 2. Definition and shortcuts Definitions:

Definition Meaning

Subscriber Entity to which the certificate is issued by CA that is the responsible of its private key.

Certification Authority Entity which execute certification process, issue the public key certificate, publish it if required, and manage revocation list.

Certificate It is the result from a process where subscriber public key and other information are associated with subscriber private key. Authenticity and integrity of this association is assured from CA. The certificate format is defined in X.509 Standard

Certification Keys Keys used form CA to generate and verify sign write down on certificate and revocation list (CRL).

Encryption keys Key pairs used to chipper some information. Cross certification It is an agreement arranged from two CA. It is used to assure the certificate and

policy validity issued by both CA. Certificate Policy According to RFC 3647, it is "a named set of rules that indicates the applicability

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

Certificate Practice Statement.

Present document. According to RFC 3647 "a CPS is a statement of the practices which a certification authority employs in issuing certificates.".

Deciphering Enciphering inverse process. Entities Independent element used inside the PKI infrastructure. CA, RA and a single

individual are all examples on entities. Enciphering Process which is used to transform the data format in another one which grants

confidentiality. Key pairs Set build up from public and private keys. Private Key Key element from the pair which is intended to be used and known only by the

subscriber. Public Key Key element from the pair which is intended to be known from everyone. User profile Subscriber cryptographic information set: private key, certificate and CA self

signed certificate. Public Key Infrastructure

Hardware, software, employers, process and rules which manage the certificate creation, distribution and revoke process.

Registration Authority Entity responsible of identifying and authorizing other entities. Security policy (SP) Rules set which define and manage security policies used to protect critical

resources. Three security levels are defined: Strategic: general directives; Sector based: specific for sector; Specific: specific for entity.

Self-signed Certificate CA public key certificate signed with related private key. Shortcuts:

Date: 21/11/2008 Pag. 8/35

Abbreviation Definition Refer

ASN.1 Abstract Syntax Notation. Used to describe information written in other standard.

CCITT, Recommendation X.208, "Specification of Abstract Syntax Notation One (ASN.1)"

CA Certification Authority See “Definitions” CAST Encryption Algorithms. RFC 2144

CP Certification Policy See “Definitions” CPS Certification Practice Statement See “Definitions”

DES Data Encryption Standard, encipher algorithm.

American National Standards Institute, ANSI X3.106, "American National Standard for Information Systems - Data Link Encryption"

DSS Digital Signature Standard. Often called DSA (Digital Signature Algorithm).

National Institute of Standards and Technology, FIPS Pub 186: Digital Signature Standard.

IESG Internet Engineering Steering Group. The group who control IETF, it choose what propose became a standard.

http://www.ietf.org/iesg.html

IETF Internet Engineering Task Force. http://www.ietf.org/

LDAP Lightweight Directory Access Protocol. Protocol to access directory X.500

RFC 1777 – RFC 2251

NIST National Institute for Standards and Technology http://csrc.nist.gov

PKI Public Key Infrastructure. See “Definitions” PKIX Internet X.509 Public Key Infrastructure. http://www.imc.org/ietf-pkix/

RFC Request For Comments: memorandum published by IETF applicable to the working of the Internet and Internet-connected systems

http://www.ietf.org/rfc.html

RSA Rivest-Shamir-Adelman. Public key encryption algorithm.

RFC 2313

SSL

Secure Sockets Layer. Protocol to cipher and authenticate Internet connection.

Hickman, Kipp, "The SSL Protocol", Netscape Communications Corp., Feb 9, 1995.

A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996.

SP Security Policy See “Definitions” TLS Transport Layer Security. Standard version of SSL RFC 2246

URI Uniform Resource Identifier RFC 2396

URL Uniform Resource Locator. RFC 1738, 1808, 2368, 2396

URN Uniform Resource Name. RFC 2141

X.500 Series of standards specifying electronic directory services.

ITU-T Recommendation X.500 (1997), ISO/IEC 9594-1:1997, Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services

X.509 Standard for Public-key and attribute certificate frameworks.

ITU-T Recommendation X.509 (1997), ISO/IEC 9594-8:1997, Information technology - Open Systems Interconnection - The

Date: 21/11/2008 Pag. 9/35

Directory: Authentication framework.

X9.42 Specific for Diffie –Hellman algorithm.

American National Standards Institute, "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV Algorithms", ANSI draft, 1998.

Date: 21/11/2008 Pag. 10/35

3. Introduction

3.1. Identification

This document is identified by file name: UGIS_CPS-1.0

3.2. Entities and applicability

This CPS is applied to entities specified in CP (in the related chapter).

3.2.1. Certification Authority (CA)

No disposition appended to what described in the related CP chapter.

3.2.2. Registration Authority (RA)


3.2.3. Subscriber


3.2.4. Applicability

Certificate issued by UGIS PKI are used in the environment specified in the related CP chapter.

3.3. Refer

3.3.1. Organization

Policies defined are under responsibility of: UniCredit Global Information Services Spa Inscription to Tribunale di Milano - Camera di Commercio: n. 101092/1997 P. IVA: 12086630154 Inscription to Albo Gruppi Bancari: cod. 3151.1 Registered office: Via Livio Cambi, 1 – 20151 Milano

3.3.2. Roles

UGIS CISO (Chief Information Security Officer) has assigned the role of the Certification Authority manager which is in charge to manage all the PKI components and entities. CA manager assigns the responsibility to issue a certificate to the certificate issuance officer, the responsibility to manage directory to directory officer, the security (logical) to security officer, the registration authority to RA officer. Certification authority manager will also assign the audit manager role which is in charge to assign the auditor roles. Auditor roles are security administrator and entity administrator. The certification authority manager is: Francesco Oliva UGIS, ICT Security Via Livio Cambi, 1 e-mail: [email protected]

Date: 21/11/2008 Pag. 11/35

4. General Conditions This section aims to describe in exhaustive way CA, RA, subscribers, and whoever uses UGIS certificates.

4.1. Duties

4.1.1. CA Duties

UGIS CA acts in accordance with the procedures defined in CP. CA uses RA to identify and communicate with subscribers. All duties which require direct contact between UGIS CA and subscribers is done by RA. UGIS CA is also not allowed to issue certificates that alter or negatively impact the functionality of any operating system or any other third party software in any manner. UGIS CA is also responsible to notify to Entrust as expeditiously as possible:

1. The event that UGIS CA is prohibited from issuing certificate for any reason; 2. The event that might materially affect UGIS CA to issue certificate in accordance with this

agreement; 3. Any facts known or suspected that materially affect the validity and reliability of certificates issued

by UGIS CA, including without limitation any suspected compromise of UGIS CA private key.

4.1.1.1. Entities Identification

No disposition appended to what described in the related CP chapter. This operation is often delegated to RA.

4.1.1.2. User Information

No disposition appended to what described in the related CP chapter. This information is available in paper and electronic format at address http://ca.unicreditgroup.eu//CP/cp.pdf.

4.1.1.3. Certificate Issuing


4.1.1.4. Certificate Management


4.1.1.5. Certificate Revocation


4.1.1.6. Other Duties


4.1.2. RA Duties

RA must act in accordance with any UGIS CA CP and CPS provision. RA must also:

• Securely store any profile that contains credentials to access RA application;

• Notify recovery process activation (key or profile) to subscriber;

• Be willing to accept UGIS CA formal audit .

4.1.3. Company Duties

Companies that adhere to UGIS PKI services must submit to the following rules:

• Inform subscriber on duties and responsibilities about key and certificate usage. RA must show how to find documentation, which must be read before request for a certificate;

Date: 21/11/2008 Pag. 12/35

• Authorize subscriber, which has the right, to request for a certificate;

• Activate revocation process in following cases: o Keys or certificate usage not in accordance with present rules; o Work relation cessation; o Certificate commissioned from subscriber which can not request for it directly.

Offices can request for certificate for their employers.

4.1.4. Subscriber Duties


4.1.5. Other Entities Duties


4.1.6. Directory Duties


4.2. Warranties and Liability Limitation

4.2.1. CA Responsibilities

It is the responsibility of the certification authority manager of the UGIS CA to ensure that the certification authority operates within the constraints imposed by Certificate Policy (CP) and Certificate Practice Statement (CPS). It shall be the responsibility of certification authority manager to generate the CA key pair.

4.2.1.1. Warranties

UGIS makes the following warranties to subscriber with respect to the operation of UGIS Certification Authority:

• UGIS CA will provide repository services consistent with the practice and procedure set forth in this CPS;

• UGIS CA will perform certificate issuance consistent with the procedure set forth in this CPS;

• UGIS CA will provide revocation services consistent with the procedure set forth in this CPS.

4.2.1.2. Limitation


4.2.2. RA Responsibilities

4.2.2.1. Warranties

The same liability provisions that apply in section 4.2.1 with respect to UGIS Certification Authority will apply with respect to UGIS Registration Authority.

4.2.2.2. Limitation


4.3. Financial Responsibilities


Date: 21/11/2008 Pag. 13/35

4.4. Interpretation of Laws


4.5. Fares


4.6. Publishing and Repository

4.6.1. Information Publishing

Certificates and CRL are published on directory server accessible through LDADv3 protocol (only for internals).at the following URI: ldap://uspkiwv01.external.usinet.it. Present document is published on web server accessible through HTTP the following URI: http://ca.unicreditgroup.eu/CPS/cps.pdf

4.6.2. Update Frequency


4.6.3. Access Control


4.6.4. Directory

UGIS directory is conformant to ISO 9594-1 (ITU X.500) and other standard from ISO 9594 family, at the location specified in par. 4.6.1. Master Directory is stored in a secure environment, together with the CA. Shadow directories, automatically replicated from the master directory, are accessible through LDAPv3 (RFC 2251) protocol. Replicating protocol between DSAs is product specific Directory shadows are accessible from intranet and internet.

4.7. Audit Process

Verification process aims to evaluate system stability and if the former is adequate to UGIS needs and to what defined in CP and CPS.

4.7.1. Frequency

Audit process frequency to CA systems is scheduled as follows:

• Every month for identification, authentication and management request process;

• Every 6 months for certificate and CRL profile ;

• Every year for environmental, security and procedural policies.

In case of remarkable events which can be attributed to employees malpractice or system failure, a verification process can be started.

4.7.2. Controller Identity and Qualification

In the following table are briefed roles and responsibilities of audit:

Management Internal and external audit approval.

Security Administrator It plans internal and external audit in agreement with audit manager.

Date: 21/11/2008 Pag. 14/35

Auditing Manager It plans with security administrator internal and external audit and the plan to submit to management for approval.

Check if there is need to execute internal and external audit not programmed but needed. It must insert these extraordinary activities into the plan.

Identify the auditors and choose auditor team leader.

Entity Administrator It supplies all information for a quick audit.

Sign audit report.

4.7.3. Relation between Collaborator and PKI

People assigned to verification process can be UGIS employer as well as employer from external society. It is mandatory that auditors can not be PKI employers.

4.7.4. Process and System Controlled

Periodic inspections are done for at least the following elements:

• Log integrity;

• Log;

• Accordance with following policies: o Confidentiality policy; o Identification and authentication; o Management requirement; o Environmental, procedural and employers security; o Technical security; o Certificates and CRL; o Policies administrator

• Backup system operations;

• HW and SW PKI configuration in accordance with CP and CPS;

• Subscriber verification: o Maintenance and protect the profile; o Storing password. o Maintenance of hardware device (if provided)

4.7.5. Action to Do in Case of Malpractice


4.7.6. Communication of results

Results from verification process are communicated to PKI and security manager. Results are considered confidential and managed in way defined in present document.

4.8. Confidentiality policy


4.9. Copyright


5. Identification and Authentication This section describes the procedures used by CA and RA to identify and authenticate entities involved in internal process:

• Initial registration;

Date: 21/11/2008 Pag. 15/35

• Certificate renewal;

• Encryption private key recovery;

• Certificate Revocation.

5.1. Initial Registration

During initial registration subscriber data are inserted through a secure channel in CA database using Administration consol.

5.1.1. Usable Names

Certificate subject field is formed by a string of names X.500 used as specified in CP.

5.1.2. Name Meaning

Names are assigned to be able to identify in a unique way subscriber certificate, in case of the same name the ID will be used appended to a sequential number (to identify multiple profiles assigned to the same subscriber).

5.1.3. Rules to Interpret Names

No disposition appended to what described in the related CP chapter. .

5.1.4. Uniqueness of Name


5.1.5. Name Conflicts Resolution


5.1.6. Company Property


5.1.7. Private Key Possession Proof

During certificate request and issuing process for a public key, CA verifies that subscriber owns the corresponding private key. This control is in accordance with RFC 2510 protocol PKIX-CMP.

5.1.8. Company Organization


5.1.9. Entities Identification

5.1.9.1. CA and RA Employee Authentication CA and RA employees are organized with the following roles:

• Master User is able to install, configure and activate PKI. It is authenticated by username and password, it is formally authenticate by responsible during PKI ceremony. Master user is responsible to configure CA services, to activate first Security Officer (which name is First Officer);

• Security officer are digital certificate owner which owns: o Certificate to authenticate to RA services; o Certificate issued by CA and associated to administrator profile.

• Administrator and Auditor are certificate owner which owns: o Certificate to authenticate to RA services.

Date: 21/11/2008 Pag. 16/35

5.1.9.2. Subscriber Authentication In order to obtain a certificate, a subscriber must request for authorization from its responsible which acts as a guarantor.

5.1.9.3. Signature and Encryption Certificate

Signature and encryption certificate do not use a specific identification/authentication procedure.

5.2. Certificate Renewal Request

Certificates are manually renewed before expiring. Subscriber must generate a new key pair and then follow the certificate issuing procedure specified in chapter 6.2. If during the last period, before certificate expires, the domain is never used, certificate is revoked. In this case all the certificates associated to subscriber profile expire, and subscriber must do identification process again.

5.3. Encryption Private Key Recovery

Encryption private key recovery can be requested from subscriber or its manager, following instructions described on next chapter.

5.3.1. Subscriber Request to Recover Encryption Private Key

A subscriber (or manager) can request its encryption private key recovery if and only if it goes personally to CA in order to be identified.

5.4. Certificate Revocation Request Authentication

The RA is in charge to authenticate who has requested the revocation. In order to do this duty it must personally check the credential of the entity which wishes to revoke the certificate.

6. Management Requirement

6.1. Certificate Request

Modalities to request e certificate change between user types:

• Internal user.

6.1.1. Internal User

Registration process is done by RA.

6.2. Certificate Issuing

Certificate issue is independent from user type. Before issuing a certificate user must register to RA information about itself, capabilities and request from subscriber. It is also mandatory to keep the indemnity letter written from subscriber which lift from any responsibilities the certification authority in case of certificate misuse In order to issue an application certificate:

• The Certificate Signing Request (CSR) is generated from subscriber hardware (if applicable) and its format is compliant with RFC 2986;

• The CSR is sent through an authenticated web application to RA ;

• RA operator verify subscriber identity and authorization and CSR integrity and validity and issues the certificate;

In order to issue Employee (encryption and signature) certificates the following steps are automatically supported trough RFC 4210 protocol (CMP):

Date: 21/11/2008 Pag. 17/35

• The subscriber generates the CSR for the signature key pair and request to CA to generate the encryption key pair;

• CA generates the encryption key pair for the subscriber and related CSR ;

• CA signs the CSRs and issues the certificates;

• CA keeps a copy of encryption private key on its database (in encrypted format);

• CA sends the certificate and private key to subscriber through a secure channel;

• Subscriber checks the content of signature and encryption certificate. CA is also responsible for:

• Publish encryption certificate on X.500 directory;

6.3. Certificate Acceptance

After receiving certificate, subscriber must control the correctness of the former. In case of mismatch with what declared it must proceed to revoke the certificate.

6.4. Certificate Revocation

6.4.1. Revocation Reasons

Certificate revocation must be requested if happens one condition described in related CP chapter (6.3.1). It can be requested urgent revocation. To the revoked certificate is assigned a revoke id (CRL Reason) which is inserted into CRL and it is used to identify the revocation reason. Codes used by UGIS PKI in accordance with x.509 are:

• Key Compromise: private key is compromised;

• CA Compromised: CA private key is compromised;

• Unspecified: undefined motivation;

• cessationOfOperation: cessation of CA activities. In case of the private key is compromised, it is also required to indicate the time in which the key was still valid. Only codes described above are used in order to grant subscriber privacy.

6.4.2. Entities which can Revoke a Certificate

Certificate revocation can be requested from:

• Subscriber;

• RA;

• CA. In the following table is described who can request the revoke and when the revocation is urgent (“U”) or normal (“N”).

Reason Subscriber RA CA

Profile recovery or certificate update N Private key is compromised U U U

Data certified wrong or obsolete U + N U + N U + N

Certificate use is not more what is meant to be U + N U + N U + N

Subscriber is not in accordance with agreement U U

CA private key is compromised U

CA cessation N

Date: 21/11/2008 Pag. 18/35

6.4.3. Certificate Revocation Request Procedure

User must be identified before they can request for a certificate revocation. After being validated from RA they make their request directly to it. RA will forward the revocation request to CA which provides to revoke the certificate. Time to make such a request is defined in CP related chapter. Revocation notification is forwarded to whom has required the revoke process.

6.4.3.1. Revoke Request from Subscriber Subscriber can request the revocation of its certificate in case described in the table defined in previous chapter. RA must:

• Verify information correctness contained into the request;

• Forward the revocation request to CA;

• In case of urgent revocation request a CRL update.

6.4.3.2. Revocation Request from RA

RA, if come to know something related to table in previous chapter will activate revocation procedure (normal and/or urgent), compiling and subscribing the revocation module. It must provide to former subscriber a notification of happened revocation.

6.4.3.3. Revocation Request Started from CA Manager

CA manager can revoke all the certificates. It must provide to former subscribers a notification of happened revocation.

6.4.4. Timing to Request for a Revocation Process

If the revocation is urgent, it must be verified and executed in the shortest time possible and anyhow in at most one hour from the moment in which the request has been made. In normal case, the revocation request must be fulfil in a period of time short enough to make it appears in the next CRL update. If the request has been made one hour before CRL update, the revocation can be shifted on the second next CRL. In this case, if the revocation does not required a field extension:”InvalidityDate”, in the request will be indicated the time of the request.

6.4.5. CRL Frequency Issuing and Availability

Appended to what specified in CP related chapter, in case of urgent revocation, it can be requested the immediate CRL issuing. In this case it will be published in the shortest time possible and it will not alter the normal CRL issuing frequency. CRL are downloaded by connecting to X.500 directory through LDAPv3 protocol. CRL will be also published through HTTP protocol available from anyone.

6.5. Control Procedures

6.5.1. Event Logged

Appended to what specified in CP related chapter, in order to permit verification and control over all operations done inside PKI infrastructure, they are logged automatically from CA. External events, which do not involve CA, are to be logged autonomously from interested systems.

6.5.1.1. CA Software Events Events logged from CA software are related to physical and logical access to PKI infrastructure, they are classified on their critical level:

• “log”: minimum level, related to normal activities (certificate request, etc);

• “event”: intermediate level, related to unusual events or events which require more then one authorization to be done. They are verified to control its legitimacy.

Date: 21/11/2008 Pag. 19/35

• “alarm”: maximum level, related to critical events. They are attempts to do unauthorized actions or hardware malfunction.

Every event is associated to an id code, which identifies operator that authorized the operation.

CA is responsible to control events:

• Activation and deactivation of CA services;

• Creation, update, deletion, activation, deactivation and profile restore events of subscriber;

• Creation, update, deletion and profile restore events of CA employers;

• Key generation, update and recovery private encryption key events;

• Certificate generation, update and revocation events;

• Backup, restore and log events;

• Programmed and not maintenance events;

• Hardware and software update.

6.5.1.2. Event Logged outside CA Environment

Following events are logged:

• Software update: automatic for some events, manual for others;

• Maintenance programmed and not: automatic for some events, manual for others;

• Site access: automatic for some events, manual for others;

• Vigilant journal;

• PKI employees update: manual.

6.5.2. Log Analysis


6.5.3. Log Maintenance

Log is stored in accordance with UGIS backup policies.

6.5.4. Log Protection

Records are identified by a progressive number which report data of their registration. They are also protected from unauthorized access. Integrity verification is automatically done from the system when an operator tries to open it. Log integrity coming from CA external system is granted by operative procedure. Log access is physical protected through storing it in secure cabinet.

6.5.5. Log Backup Copy


6.5.6. Log Storing


6.5.7. Notification to Subject which Caused Critical Events

As well as storing log on file, system will signal as fast as possible to operator whenever an operation execution did not went right, trying to identify the cause of malfunction.

Date: 21/11/2008 Pag. 20/35

6.5.8. Vulnerability Assessment


6.6. Information Stored

6.6.1. Information Stored Types

CA stored following information types:

• Subscriber data supplied at registration tier;

• Paper or electronic documentation about certificate request and issue;

• Indemnity letter;

• Private encryption key of subscriber;

• Key, profile and revocation request recovery;

• Issued Certificate;

• Cross Certification Document with Entrust.

6.6.2. Archive Storing Living Range

Certificate, encryption key and CRL are stored for 10 years. Paper documentation is stored for 10 years.

6.6.3. Archive Protection

Information protection is granted by security and procedural policies already present in UGIS. Certificate, keys and CRL stored are protected through encryption using CA software.

6.6.4. Archive Backup

Database containing stored information is subjected to a complete backup one time a day. Paper information are edited in duplicate. Copies are stored in separate archive.

6.6.5. Time Identification in Log File


6.6.6. Procedure to Verify and Obtain Information Stored


6.7. Keys Renewal

6.7.1. Subscriber Keys Renewal

Appended to what specified into CP related chapter, in case of key stored into a cryptographic hardware that does not work anymore, subscriber must recover the key from malfunctioning hardware and put it into a new one. Subscriber must also destroy the former hardware. Destroyed hardware must be given to RA which will edit documentation about this procedure.

6.7.2. CA Key Renewal

CA keys will be renewed every 10 years, three months before expiring date or in case of malfunctioning which does not derive from key tampering. Renewal process is composed by:

• Issuing new key pairs;

• Publishing on directory of: o Certificate with new public key, signed with old private key; o Certificate with new public key, signed with new private key; o Certificate with old public key, signed with new private key.

Date: 21/11/2008 Pag. 21/35

This is a cross certification process, which gives validity to new keys as heirs from old key, without stopping trust relationship. In every certificate “Issuer” field always contains the same distinguish name while “authoritykeyidentifier” is unique for every key pair because it is given from public key SHA-1 fingerprint. This fingerprint makes able to always identify correct public key. Procedure must be logged inside a paper document for audit process.

6.8. Emergency Procedure and Disaster Recovery

UGIS has developed emergency and DR procedure. In this document only non confidential information are described. Main disasters are the following:

• Environmental disaster;

• CA keys is compromised;

• Hardware and software malfunction.

6.8.1. Environmental Disaster

UGIS disaster recovery plan is composed by following fail back:

• Emergency management: CRL issued are available, new certificate and CRL can be slow down at maximum for a period indicates into CP related chapter, if it is necessary backup process must be activated;

• Temporary operation: Functionalities are normally available on DR or production site, in the first case some activities will be started to return operation on production system;

• Normal operation restore: production system is normally back on line. To activate these processes exhaustive documentation was edited. Personal data stored on device which can be stole during these operations are ciphered.

6.8.2. CA Key Revocation

If CA private key to sign certificate is compromised it must be revoked. It will be generated a new key pair as described in previous chapters. Certificate issued with compromised key will be revoked with reason “CACompromise”. Revoking CA certificate means render invalid every certificate issued from it. In case of revocation a paper format document must be edited and notified to all subscribers and to Entrust. In this document it must be indicated how CA wants to continue its duty. If a new key pair is generated cross certification with Entrust must be recreated.

6.8.3. Hardware and Software Malfunction

In case of hardware and software malfunction a minimal subset of operations described in previous chapter are applied.

6.9. CA Activity Cessation

In case of CA wants to cease its activity it must:

• Inform in advance (specified in CP related chapter) about the cessation date CA Entrust and the certificate subscribers. The former must be informed through email;

• Inform entities in case of the CA activities will be taken over from another CA;

• Inform which company will store documentation until expiring date, the modalities in which archives are published and for how much time they will be stored;

• Revoke valid certificate;

• Generate and publish the last CRL which will be available until natural expiring date of last certificate is spent;

• Destroy CA signature key. Every operation will be made in presence of people indicated for CA key generation. A document will be edited and stored from company which will take UGIS CA place.

Date: 21/11/2008 Pag. 22/35

7. Environmental, Procedural and Operational Security Policies

7.1. Environmental Security Policies

7.1.1. Building

Every certification systems are located in a protected area; the access is limited to a small set of people and is controlled round the clock from a camera connected to the central operative site.

7.1.1.1. Production Site The building is surrounded by impassable walls, the only access point are protected by door activated by a magnetic badge. Building were the server are located are closed, with access control to every door. All the room are equipped with conditioning air. All sites have its fire measures.

7.1.2. Physical Access

Physical access to the building is controlled by guards which allow entrance according to the following rules:

• Show company badge;

• Identification of employee who does not have badge and supplying it with a temporary one;

• Id documentation identification and registration in case of a visit from a non employee. A temporary badge will be supplied to it. The visiting guest must be followed by its sponsor during the visit.

7.1.2.1. CA

The access to CA system is allowed only for authorized employees. Access is controlled by magnetic badge. The room is removed from public areas such as roads or open space. PKI system is clearly identified and distinguished from other systems and it is used only for public key infrastructure purpose. In this site there must be at least two operators at the same time. Employees which execute extraordinary maintenance must be controlled while the maintain lasts. Entering and exiting from the room is registered and periodically controlled.

7.1.2.2. RA During work hours RA operates in site which does not need control access apart from the one used to access the building. Protections adopted on RA hardware are the following:

• RA systems must not be used from other people without subscriber approval. In case on maintenance only authorized employers are authorized to work on it.

• Automatic log out from the application is in place in case of any operation for some time;

• IDS are used to block and identify unauthorized access;

• Hashing mechanism are used to control hardware modification;

• Password is protected from unauthorized access.

Antivirus software must be also installed. It must be periodically updated.

7.1.2.3. Subscriber

Subscriber are personally responsible for hardware and application given to them, they must protect password to access the profile, without write it down on device freely available to anyone. If key are stored on external devices, responsible must take care of these devices without letting anyone access the devices. Applications which use key are programmed to make an automatic log out after few minutes of inactivates. Antivirus software is installed and periodically update.

Date: 21/11/2008 Pag. 23/35

7.1.3. Energy, Wiring and Air


7.1.4. Water Exposure


7.1.5. Fire Measurement


7.1.6. Storing Device

Storing device for CA and RA are located into building with access control and suitable environment. Their management is made from the buying procedure (free of error, virus, etc) to its cessation where the device is physically destroyed.

7.1.7. Garbage Management


7.1.8. Storing in other Place


7.2. Procedural Security

In the following chapters are defined rules to give responsibilities between PKI employees. Roles and requested authorization for operations are defined.

7.2.1. Profiles

7.2.1.1. CA Profiles Profiles which define CA roles are the following:

• CA Manager;

• Certificate Issuance officer;

• Directory officer;

• Security officer;

• RA officer;

• Auditor manager. Some critical operations can only be done if more entities act together. Some functional profile can not be assigned to the same person as shown in the following table:

Duty Role

PKI entities management

Cert. management

Directory Management

Identification Data Security

Auditing

CA Manager X

Cert. Issuance officer

X Yes Yes

Directory officer

Yes X Yes

RA officer X Yes Security officer Yes Yes Yes X

Date: 21/11/2008 Pag. 24/35

Auditor manager

X

7.2.2. Number of People Needed for Operations

In order to perform some CA operations the presence of more people is needed. In the following table it is specified the maximum number of authorization needed for critical operations.

Role N. of authorized people

Minimum number of people

Cert. issuance officer 3 1

RA Officer 1 1

Security Officer 5 2

Directory officer 3 --

7.2.3. CA Employees Recognition

CA employees are authenticated with modalities described in previous chapters.

7.3. Employees Security

Appended to what specified in CP related chapter, the following disposition are applied. To PKI employees can not be assigned incompatible duties:

• A duty can not control another duty;

• A duty can not limit the execution of another duty;

• Two duties can not control a third duty;

• To PKI employees can not be assigned other duties which are in contrast with PKI duties. PKI employees must declare through a paper format document to be aware of duties and responsibilities of their role (and the consequence for malpractice).

7.3.1. Employees

PKI employees are controlled by company responsible. Company responsible are not authorized to execute activities which are in charge of employers.

7.3.2. Qualification and Experience

CA and RA employers are chosen by their experience and qualification. They have established substantial experience (5 years) about system management and they have attended specific course to manage the implemented PKI.

7.3.3. Formation

CA and RA employers competences are enrich with periodic formation courses about their specific role, in particular:

• PKI software use;

• PKI hardware use (cryptographic device, etc);

• Security measure about profile;

• Operational procedures described in CPS;

• Emergency procedure.

7.3.4. Frequency of Update

Update courses are made with one (1) year period; they are variable within the role and PKI infrastructure change.

Date: 21/11/2008 Pag. 25/35

7.3.5. Profile Shifting

In order to avoid management difficulties due to PKI employees absences, profiles are shifted with a period of one year.

7.3.6. Fee for Not Authorized Operations

Fees for not authorized operations are defined by employer responsible.

7.3.7. Documentation

CA and RA employers are supplied with all the necessary documentation which describes in exhaustive way the rule involved in the process: product manual, CP, CPS, specific procedures, emergency plan.

Date: 21/11/2008 Pag. 26/35

8. Technical Security This section describes security measures adopted by UGIS CA to protect keys, certificates, and information about certification activities.

8.1. Generation and Storing of the Keys

8.1.1. Key Generations

8.1.1.1. CA CA keys are generated in front of at least 2 operators, master user or security officer. The procedure will be activated after authenticating to the system. Private keys are memorized on CA database ciphered. Documentation is signed by operators which have done the generation process and stored for audit.

8.1.1.2. Subscriber Subscriber generates signature key pair; private key is stored inside user profile and protected through encryption. CA generates subscriber public and private encryption keys; private key is stored into the profile and protected through encryption by CA.

8.1.2. Releasing of Encryption Private Keys to Subscriber

CA send, through a secure channel in accordance with RFC 2510, the encryption private keys to subscriber. The channel is created when the subscriber authenticates itself to the PKI.

8.1.3. Releasing of Public Keys to CA

Encryption public key is generated by the CA and it is published on X.500 directory.

8.1.4. Releasing of CA Public Key to Subscriber

CA public key and related self signed certificate is published on directory and/or sent to subscriber through email.

8.1.5. Key Length

CA and subscriber key length are described in the certificate template document.

8.1.6. CA Key Generation

CA keys pair are generated via FIPS-140 level 3 hardware and stored through encryption in hardware device. Application certificate keys are generated via hardware. Signature certificate keys are generated by subscriber; they are stored into user profile and protected through encryption. Encryption certificate keys are generated by CA; they can be stored into a hardware device (smartcard) or in property Entrust format on filesystem.

8.1.7. Certificate Use

In every certificate it is specified what is its purpose in accordance with CP (in the related chapter). Key usage field can assume following value:

• digitalSignature and nonRepudiation for encryption and sign certificate (individual);

• keyEncipherment for encryption certificate (individuals);

• KeyCertSign and CRLSign for CA certificate.

Date: 21/11/2008 Pag. 27/35

This specification is also achieved by setting the correct value to “KeyPurpouseId” of Extended KeyUsage field which refines KeyUsage Field. The values that can be assigned are:

• TLS web Server Authentication.

8.2. Private Keys Protection

8.2.1. Enciphering Module Standard

Every ciphering operations made by CA, RA and subscriber are made through hardware and/or software device.

8.2.2. Private Keys Management

The activation of CA signature key is made through a “m of n” (two of three) operation based on Shamir Shared Scheme. Recovery of encryption private key for users is necessary in one of the following;

• Subscriber forget its password to unlock profile;

• Profile is damaged or unusable;

• Hardware device where key is stored (when provided) is lost or damaged. Recovery must be asked from subscriber or its responsible following modalities described in above chapters.

8.2.3. Signature Private Key escrow

Private signature key is property to its subscriber. In order to grant non repudiation, the private key must not be given to anyone.

8.2.4. Private Key Backup

A backup of CA private key is copied on hardware device and stored in a secure place. No backup is made on application private key. No backup is made on signature key (users). A ciphered copy of private encryption key for every individual is kept by CA.

8.2.5. Private Key Storing

Refer to previous chapter.

8.2.6. Inserting of Private Key in Cryptographic Module


8.2.7. Private Key Activation

The private key became active after subscriber access its profile (if profile is stored onto a file). Password inserted unlocks the credentials, if a connection to X.500 directory is available then the certificate validity is checked. If these two steps go well, subscriber is able to use its keys; otherwise the profile remains locked.

8.2.8. Private Key Deactivation

Private key is disabled when subscriber log off from its profile (only if profile is stored onto a file in Entrust format).

Deactivation is also done automatically after few minutes of inactivity.

Date: 21/11/2008 Pag. 28/35

8.2.9. Private Key Destruction

8.2.9.1. Cryptographic Device At the end of cryptographic device activities like smart-card, private key stored in it must be destroyed. This operation can be done in following ways:

• Initializing again cryptographic device;

• Physically destroying the smart card.

8.2.9.2. Profile Stored on Local Disk In case the profile is stored onto local disk it must be deleted in a way it is not possible to restore it anymore.

8.3. Other Management Key Aspect

8.3.1. Public Key Filing

Public key and related certificate is stored by CA in accordance with procedure previously described.

8.3.2. Key Pair Life Cycle

CA key has a life range of 10 years. After that period the key must be renewed. Self signed certificate has a life range of 7 years. Private encryption key and related certificate have a life range of 3 years. Private signature key and related certificate have a life range of 2 years.

8.4. Activation Data

8.4.1. Activation Data Generation and Installation

8.4.1.1. CA CA employers will receive installation code to install CA software. They must be at least 2.

8.4.2. Activation Data Protection

Every PKI employers must adopt right measurement in order to grant the confidentiality of activation code.

8.5. Computer Security

PKI systems are located in protected building with access control. Operating system is periodically subjected to hardening procedures. Access to software from users is subjected to strong authentication through certificate.

8.6. Network Security

Network security to CA and x.500 directory are described in the document: ”PKI network infrastructure”.

Date: 21/11/2008 Pag. 29/35

9. CRL and Certificate

9.1. Subscriber Certificate Profile

Refer to the appendix.

9.2. CRL Profile

CRL is in accordance with ITU-T X.509v3 standard; its version is X.509v2. reasonCode extension can be set only for the following CRLReason:

• Unspecified;

• KeyCompromise;

• Superseded;

• cessationOfOperation. It is also possible to specify “invalidityDate” field to indicate last validity date for the key.

Date: 21/11/2008 Pag. 30/35

10. Policy Management

10.1. New Practice Statements

New CPS can be released if significant modifications about certificate issuing and management, certificate types or PKI management occur. New CPS will be published on the same address then previous one and can be appended or substitute the former.

10.2. CPS Update

10.2.1. Elements Updatable without Warning

Elements that can be updated without warning are:

• Grammatical correction;

• Update regarding roles.

10.2.2. Elements Updatable with Warning

If update made to this CPS is significant, a warning must be given:

• Update to procedure which manage certificate life cycle: not more than 10 days;

• Update to structural PKI management: not more then 20 days;

• Update to certificate profile: not more than 20 days.

10.2.3. Update Notification

Subscriber, PKI employers and Entrust must receive notification about update. Notification can be sent through email. In the email it must be inserted, where possible, the update made for new document.

10.2.4. Comment

Entity who complains about update can send its comments to CA manager. Comments must be sent within 2 days after notification.

10.2.5. Comment Management

Comments to update are subjected to CA manager. Comments will be stored in accordance with the procedure.

10.2.6. Correction Applicability

The applicability of a possible correction derived from a comment will not require a further notification.

Date: 21/11/2008 Pag. 31/35

11. Appendix A: Verification about Certificate Validity When a user verifies certificate validity it must validate following elements:

• Valid certification path;

• Certificate is not revoked or expired;

• Certification path is composed of:

• Self signed certificate of CA public key supplied to subscriber;

• Cross certificated CA certificate (Entrust). To these elements in case of CA key renewal, are appended in accordance with RFC 2510 the following certificate:

• Certificate of old public key signed with new private key (“old-with-new”);

• Certificate of new public key signed with old private key (“new-with-old”). Verification process about expired certificate is made by controlling CRL published on directory. It must be verified that the time contained in field “nextUpdaate” of CRl is not expired. Digital sign is not valid when:

• It is not possible to access a valid CRL;

• Certificated related to signed document is expired:

• Certificate related to signed document is revoked;

Date: 21/11/2008 Pag. 32/35

12. Appendix B: Certificate Template CA Certificate

Version Version 3

Serial number Automatically given from CA

Signature SHA-1, RSA

Issuer Country: “IT”

Organization: “UGIS S.p.A.”

Organization Unit: “ICT Security Office”

Organization Unit: “Servizi di Certificazione”

Validità 10 years

Subject Country: “IT”




SubjectPublicKeyInfo 2048 bit

Algorithm used: RSA

Extension

Authority Key Identifier Issuer Key Identifier

Subject Key Identifier Keyidentifier

KeyUsage Certificate Sign

CRL Sign (Critical)

Basic Constraint CA = TRUE (Critical Critica)

Certificate Policy Policy OID: 1.3.76.40.2.1

CPS: http://ca.unicreditgroup.eu/CP/cp.pdf

CRL Distribution Point 1) URIName http: “http://ca.unicreditgroup.eu/CRL/ca.crl

2)ldap: “ldap://ldap.unicreditgroup.eu.it/ou=Servizi%20di%20Certificazione, ou= ICT%20Security%20Office,o=Unicredit%20Group%20S.p.A.,c=IT?certificate RevocationList?base

3) DirName X.500

Date: 21/11/2008 Pag. 33/35

SSL Certificate

Version Version 3

Serial number Automatically given by CA


Issuer Country: “IT”




Validità 1 year

Subject Country: “IT”

Organization: “Banca di Roma”

Organization Unit: “Ufficio Interni”

Organization Unit: “Applicativi”

Common name: “domain name”

SubjectPublicKeyInfo Minimum 1024 bit public key

Algorithm used: RSA

Extension


Subject Key Identifier keyIdentifier

KeyUsage Digital Signature

Key Encipherment

Extended KeyUsage id_kp_serverAuth (1.3.6.1.5.5.7.3.1)

Basic Constraint Subject Type=End Entity

Certificate Policy Policy OID: 1.3.76.40.2.1__N

CP: http://ca.unicreditgroup.eu/CP/cp.pdf

CRL Distribution Point 1) URIName http: “http://ca.unicreditgroup.eu/CRL/ca.crl

2)ldap: “ldap://ldap.unicreditgroup.eu/ou=Servizi%20di%20Certificazione, ou= ICT%20Security%20Office,o=Unicredit%20Group%20S.p.A.,c=IT?certificate RevocationList?base

3) DirName X.500

Date: 21/11/2008 Pag. 34/35

EncryptionCertificate

Version Version 3

Serial Number Automatically given by CA


Issuer Country: “IT” Organization: “UGIS S.p.A.” Organization Unit: “ICT Security Office” Organization Unit: “Servizi di Certificazione”

Validity 2 years

Subject

Country: “IT” Organization: “UGIS S.p.A” Organization Unit: “Office” Organization Unit: “Subscriber” Common name: “Subscriber Name and Surname” SerialNumber: “Subscriber id”

SubjectPublicKeyInfo 1024 bit public key Algorithm used: RSA

Extension


Subject Key Identifier KeyIdentifier

KeyUsage Key Encipherment

Extended KeyUsage Id_kp_emailProtection(1.3.6.1.5.5.7.3.4)

Subject Alternate Name Email RFC822

Certificate Policy Policy OID: 1.3.76.40.2.1__N CP: http://ca.unicreditgroup.eu/CP/cp.pdf User Notice: explicitText: The holder must use the certificate only for the purposes for which it is issued.

CRL Distribution Point 1) URIName http: “http://ca.unicreditgroup.eu/CRL/ca.crl 2) URIName ldap: “ldap://ldap.unicreditgroup.eu/ou=Servizi%20di%20Certificazione,o=UGIS%20S.p.A.,c=IT?certificate RevocationList?base 3) DirName X.500

Date: 21/11/2008 Pag. 35/35

Sign Certificate

Version Version 3

Serial Number Automatically given by CA


Issuer Country: “IT” Organization: “UGIS S.p.A.” Organization Unit: “ICT Security Office” Organization Unit: “Servizi di Certificazione”

Validity 2 years

Subject

Country: “IT” Organization: “UGIS S.p.A” Organization Unit: “Office” Organization Unit: “Subscriber” Common name: “Subscriber Name and Surname” SerialNumber: “Subscriber id”

SubjectPublicKeyInfo 1024 bit public key Algorith used: RSA

Extension


Subject Key Identifier KeyIdentifier

KeyUsage Non Repudiation Extended KeyUsage Not present

Subject Alternate Name Not present

Certificate Policy Policy OID: 1.3.76.40.2.1__N CP: http://ca.unicreditgroup.eu/CP/cp.pdf User Notice: explicitText: The holder must use the certificate only for the purposes for which it is issued.

CRL Distribution Point 1) URIName http: “http://ca.unicreditgroup.eu/CRL/ca.crl 2) URIName ldap: “ldap://ldap.unicreditgroup.eu/ou=Servizi%20di%20Certificazione,o=UGIS%20S.p.A.,c=IT?certificate RevocationList?base 3) DirName X.500

Date post:	10-Jun-2018
Category:	Documents
Upload:	trannhi
View:	230 times
Download:	0 times

Certificate Infrastructure Certificate Practice …ca.unicreditgroup.eu/CPS/cps.pdfCertificate...

Documents