certification practice statement · certification practice statement ssl server and code signing...

Certification Practice Statement

SSL Server and Code Signing certificates

Version: 2.3

Date: 09 December 2014

Certification Practice Statement

SSL Server and Code Signing certificates

Written by: Adriano Santoni

Resp. Security

Date Verified by: Fabio Omenigrandi

Resp. Technical Services

Date Verified by: Rosalia Valsecchi

Resp. Certification

Date Verified by: Roberto Ravazza

Resp. Operations

Date Verified by: Giorgio Marzorati

Internal Auditor

Date Approved by Giorgio Girelli

Director General

Date

Document Code:

CAACT-03-01-04

Distribution:

PUBLIC

CAACT-03-01-04 Certification Practice Statement

Copyright © Actalis S.p.A. Page 2 of 49 09 December 2014

Change History

DATE VERS. PARAGRAPHS CHANGES AUTHOR

14 Dec. 2005 1 - Initial release FP

24 June 2009 2 all Complete review of document in accordance with RFC 3647

FP, AS

19 Nov. 09 2.0.1 1.3.1 Changed name of President AS

13 May 2010 2.0.2 3.4 Removed sentence referring to private IP addresses in certificates (that is not allowed)

AS

18 May 2010 2.0.3 4.2, 8.1, 8.2, 8.4, 8.5, 8.6,

9.5.2, 9.8

Clarifications and integrations related to RAs AS

18 May 2010 2.0.3 1.3.1 Updated Actalis’ address; corrected the given name of the President.

AS

14 June 2011 2.0.4 1.3.1, 3.1, 4.1 Updated Actalis’ legal representative. Clarified I&A and pre-issuance checks for

wildcard and multi-SAN certificates

AS

28 Sep 2011 2.1.0 all Transition to a 2-level CA hierarchy (Root CA, SubCA). Added details about management of CA keys. Clarified that two-factor authentic-

ation is required for all accounts allowing certificate issuance. Clarified that certificate

serial numbers include at least 8 random bytes. SHA-256 used for certificate and CRL issuance. Updated minimum key lengths.

AS

6 Nov 2013 2.2.3 all Alignment to Italian CPS v2.2.3 AS

13 Nov 2013 2.2.4 all Updated name of Actalis CEO in §1.3.1. New section 4.13 on certificate problem reporting.

Modified §1.3.2 to cover Enterprise RAs. Addedd OV profiles in §1.4 and in chapter 7. Modified §3.1 for more clarity. Clarifications

in §3.3 regarding checks. Clarifications on the use CNames in CRL and OCSP URLs.

AS

14 Feb 2014 2.2.5 all CAB Forum compliance made explicit at beginning of chapter 3. Clarification about

IDNs.

AS

03 Sep 2014 2.2.6 3.1.1, 4.13, 6.33

Clarified that hostnames are not allowed in Code Signing certificates. Added phone

number for certificate problem reporting. Keys of 1024-bits are not allowed anymore.

AS

20 Oct 2014 2.2.7 all Added support of DV (Domain Validated) certificates. Added digital signature as a means to validate individual identities.

Correction of typos and some clarifications.

AS

9 Dec 2014 2.3 all Correction of typos. AS



Table of Contents

1. INTRODUCTION ........................................................................................................................................ 6

1.1 OVERVIEW .................................................................................................................................................. 6 1.2 DOCUMENT IDENTIFICATION ........................................................................................................................... 6 1.3 PARTICIPANTS TO PUBLIC KEY INFRASTRUCTURE (PKI) ......................................................................................... 6

1.3.1 Certification Authority ..................................................................................................................... 6 1.3.1.1 Root Certification Authority ......................................................................................................................... 7 1.3.1.2 Subordinate Certification Authority ............................................................................................................. 7

1.3.2 Registration Authorities ................................................................................................................... 7 1.3.3 Subscribers ....................................................................................................................................... 8 1.3.4 Relying parties ................................................................................................................................. 8

1.4 USE OF CERTIFICATES ..................................................................................................................................... 8 1.5 ADMINISTRATION OF CPS .............................................................................................................................. 9 1.6 DEFINITIONS AND ACRONYMS ......................................................................................................................... 9 1.7 LIST OF REFERENCES .................................................................................................................................... 10

2 PUBLICATIONS AND REPOSITORY ............................................................................................................11

2.1 REPOSITORY MANAGEMENT .......................................................................................................................... 11 2.2 PUBLISHED INFORMATION ............................................................................................................................ 11 2.3 TIME AND FREQUENCY OF PUBLICATIONS ......................................................................................................... 11 2.4 ACCESS CONTROL ....................................................................................................................................... 11

3 IDENTIFICATION AND AUTHENTICATION (I&A) .......................................................................................12

3.1 NAMING RULES .......................................................................................................................................... 12 3.1.1 For all certificate classes ................................................................................................................ 12 3.1.2 For EV-class certificates ................................................................................................................. 13 3.1.3 For DV-class certificates ................................................................................................................. 13

3.2 INITIAL IDENTITY VALIDATION ........................................................................................................................ 13 3.2.1 Proving possession of private key .................................................................................................. 13 3.2.2 Authentication of organization identity......................................................................................... 13 3.2.3 Authentication of individual identity ............................................................................................. 14

3.3 FURTHER VERIFICATIONS BY THE CA ............................................................................................................... 14 3.3.1 For all classes of SSL Server certificates ......................................................................................... 14

3.3.1.1 Internationalized Domain Names (IDN) ..................................................................................................... 15 3.3.2 For EV-class certificates ................................................................................................................. 15

3.4 INFORMATION NOT VERIFIED BY THE CA .......................................................................................................... 15 3.5 I&A FOR RENEWAL APPLICATIONS .................................................................................................................. 16 3.6 I&A FOR REQUESTS TO SUSPEND OR REVOKE .................................................................................................... 16

4 CERTIFICATE MANAGEMENT OPERATIONAL REQUIREMENTS .................................................................16

4.1 CERTIFICATE APPLICATION ............................................................................................................................ 16 4.2 APPLICATION PROCESSING ............................................................................................................................ 17 4.3 ISSUE OF CERTIFICATES ................................................................................................................................. 17 4.4 CERTIFICATE ACCEPTANCE ............................................................................................................................ 18 4.5 USE OF KEY PAIR AND CERTIFICATE ................................................................................................................. 18 4.6 CERTIFICATE RENEWAL ................................................................................................................................. 18 4.7 KEY RE-GENERATION ................................................................................................................................... 18 4.8 CERTIFICATE MODIFICATION .......................................................................................................................... 19 4.9 CERTIFICATE SUSPENSION AND REVOCATION .................................................................................................... 19

4.9.1 Reasons for suspension .................................................................................................................. 19 4.9.2 Request for suspension .................................................................................................................. 19 4.9.3 Suspension procedure .................................................................................................................... 19 4.9.4 Certificate revocation .................................................................................................................... 20 4.9.5 Revocation request ........................................................................................................................ 21



4.9.6 Procedure for suspension or revocation ........................................................................................ 21 4.9.7 Frequency of issue of CRL............................................................................................................... 21

4.10 CERTIFICATE STATUS INFORMATION ................................................................................................................ 21 4.10.1 Operational characteristics ............................................................................................................ 21 4.10.2 Service availability ......................................................................................................................... 22

4.11 CONTRACT TERMINATION ............................................................................................................................. 22 4.12 KEY ESCROW AND RECOVERY ......................................................................................................................... 22 4.13 CERTIFICATE PROBLEM REPORTING ................................................................................................................. 23

5 PHYSICAL AND OPERATIONAL SECURITY CONTROLS ...............................................................................23

5.1 PHYSICAL SECURITY ..................................................................................................................................... 24 5.2 PROCEDURAL CONTROLS .............................................................................................................................. 24 5.3 PERSONNEL CONTROLS ................................................................................................................................ 24 5.4 EVENT LOGGING ......................................................................................................................................... 24 5.5 DATA RETENTION AND ARCHIVAL ................................................................................................................... 25 5.6 RENEWAL OF CA KEY ................................................................................................................................... 25

5.6.1 Root CA .......................................................................................................................................... 25 5.6.2 Sub CA ............................................................................................................................................ 25

5.7 BACKUP COPY ............................................................................................................................................ 25 5.8 COMPROMISE AND DISASTER RECOVERY .......................................................................................................... 25 5.9 CESSATION OF THE CA ................................................................................................................................. 26

6 TECHNICAL SECURITY CONTROLS ............................................................................................................26

6.1 KEY GENERATION ........................................................................................................................................ 26 6.1.1 Root CA .......................................................................................................................................... 26 6.1.2 Sub CA ............................................................................................................................................ 27 6.1.3 Subscribers ..................................................................................................................................... 27

6.2 DISTRIBUTION OF PUBLIC KEY ........................................................................................................................ 27 6.2.1 Root CA .......................................................................................................................................... 27 6.2.2 Sub CA ............................................................................................................................................ 27 6.2.3 Subscribers ..................................................................................................................................... 27

6.3 KEY SIZE .................................................................................................................................................... 27 6.3.1 Root CA .......................................................................................................................................... 27 6.3.2 Sub CA ............................................................................................................................................ 27 6.3.3 Subscribers ..................................................................................................................................... 27

6.4 PARAMETERS GENERATION AND KEY QUALITY ................................................................................................... 28 6.4.1 Root CA .......................................................................................................................................... 28 6.4.2 Sub CA ............................................................................................................................................ 28 6.4.3 Subscribers ..................................................................................................................................... 28

6.5 KEY USAGE (X.509V3 EXTENSION) ................................................................................................................. 28 6.5.1 Root CA .......................................................................................................................................... 28 6.5.2 Sub CA ............................................................................................................................................ 28 6.5.3 Subscribers ..................................................................................................................................... 28

6.6 PROTECTION OF PRIVATE KEY ........................................................................................................................ 28 6.6.1 Root CA .......................................................................................................................................... 28 6.6.2 Sub CA ............................................................................................................................................ 29 6.6.3 Subscribers ..................................................................................................................................... 29

6.7 SECURITY STANDARD FOR CRYPTOGRAPH MODULES ........................................................................................... 29 6.8 PRIVATE KEY (N OUT OF M) MULTI-PERSON CONTROL ....................................................................................... 29

6.8.1 Root CA .......................................................................................................................................... 29 6.8.2 Sub CA ............................................................................................................................................ 29 6.8.3 Subscribers ..................................................................................................................................... 29

6.9 BACKUP AND RECOVERY OF PRIVATE KEY .......................................................................................................... 29 6.9.1 Root CA .......................................................................................................................................... 29 6.9.2 Sub CA ............................................................................................................................................ 29 6.9.3 Subscribers ..................................................................................................................................... 29

6.10 KEY ACTIVATION DATA ................................................................................................................................. 30



6.10.1 Root CA .......................................................................................................................................... 30 6.10.2 Sub CA ............................................................................................................................................ 30 6.10.3 Subscribers ..................................................................................................................................... 30

6.11 COMPUTER SECURITY REQUIREMENTS AND CONTROLS........................................................................................ 30 6.12 NETWORK SECURITY REQUIREMENTS AND CONTROLS ......................................................................................... 30 6.13 CLOCK SYNCHRONISATION ............................................................................................................................ 31

7 CERTIFICATE AND CRL PROFILES ..............................................................................................................32

7.1 CERTIFICATE PROFILE ................................................................................................................................... 32 7.1.1 Root CA .......................................................................................................................................... 32 7.1.2 Sub CA ............................................................................................................................................ 33 7.1.3 SSL Server EV (Extended Validation) .............................................................................................. 34 7.1.4 Code Signing EV (Extended Validation).......................................................................................... 35 7.1.5 SSL Server OV (Organization Validated) ........................................................................................ 36 7.1.6 SSL Server Wildcard OV (Organization Validated) ......................................................................... 37 7.1.7 Code Signing OV (Organization Validated) .................................................................................... 38 7.1.8 SSL Server DV (Domain Validated) ................................................................................................. 39 7.1.9 SSL Server Wildcard DV (Domain Validated) ................................................................................. 40

7.2 CRL PROFILE .............................................................................................................................................. 41

8 COMPLIANCE AUDITS AND OTHER ASSESSMENTS ...................................................................................41

8.1 FREQUENCY OR CIRCUMSTANCES OF ASSESSMENT ............................................................................................. 41 8.1.1 Root CA .......................................................................................................................................... 41 8.1.2 Sub CA ............................................................................................................................................ 41 8.1.3 Registration Authorities ................................................................................................................. 41

8.2 IDENTITY AND QUALIFICATION OF ASSESSOR ..................................................................................................... 42 8.3 ASSESSOR’S RELATIONSHIP TO ASSESSED ENTITY ................................................................................................ 42 8.4 TOPICS COVERED BY ASSESSMENT .................................................................................................................. 42 8.5 ACTIONS TAKEN AS A RESULT OF DEFICIENCY ..................................................................................................... 42 8.6 COMMUNICATION OF RESULTS ...................................................................................................................... 42

9 OTHER BUSINESS AND LEGAL MATTERS ..................................................................................................43

9.1 SERVICE FEES ............................................................................................................................................. 43 9.2 FINANCIAL RESPONSIBILITY ........................................................................................................................... 43 9.3 PRIVACY OF PERSONAL INFORMATION ............................................................................................................. 43

9.3.1 Information pursuant to Legislative Decree n.196/2003 ............................................................... 43 9.3.2 Archives containing personal information ..................................................................................... 44 9.3.3 Privacy protection measures.......................................................................................................... 44

9.4 INTELLECTUAL PROPERTY RIGHTS .................................................................................................................... 44 9.5 OBLIGATIONS AND GUARANTEES .................................................................................................................... 44

9.5.1 Certification Authority ................................................................................................................... 44 9.5.2 Registration Authority ................................................................................................................... 45 9.5.3 Subscribers ..................................................................................................................................... 45 9.5.4 Relying parties ............................................................................................................................... 46

9.6 DISCLAIMERS OF WARRANTIES ....................................................................................................................... 46 9.7 LIMITATIONS OF LIABILITY ............................................................................................................................. 46 9.8 INDEMNITIES ............................................................................................................................................. 46 9.9 TERM AND TERMINATION ............................................................................................................................. 47 9.10 CORRESPONDENCE ...................................................................................................................................... 47 9.11 AMENDMENTS ........................................................................................................................................... 47 9.12 RESOLUTION OF DISPUTES ............................................................................................................................ 47 9.13 APPLICABLE LAW ........................................................................................................................................ 47 9.14 COMPLIANCE WITH APPLICABLE LAW .............................................................................................................. 47 9.15 FORCE MAJEURE ......................................................................................................................................... 47 9.16 SERVICE LEVELS .......................................................................................................................................... 48



1. Introduction

1.1 Overview

Actalis S.p.A. has been a leading provider since 2002 of certification services, accredited by AgID under the EU

Electronic Signatures Directive, and offers several types of certificates and related management services, as

well as other services and solutions (www.actalis.it).

A certificate binds a public key to a set of information that identifies an entity (individual or organization). This

entity, the subscriber or owner of the certificate, possesses and utilizes the corresponding public key. The cer-

tificate is generated and supplied to the owner by a trusted third party known as Certification Authority (CA).

The certificate is digitally signed by the CA.

The reliability of a certificate, in other words the dependable association of a given public key with the identi-

fied subject, also depends on the CA’s operating procedures, the obligations and responsibilities between the

certification authority and subscriber, and the CA’s physical and logical security controls. All those aspects are

described in a public document called Certification Practice Statement (CPS).

This document is Actalis’ CPS relevant to the issuance and management of two types of certificates:

SSL Server certificates

Code Signing certificates

The structure of this CPS conforms to the public specification [RFC 3647].

Within the Certification Authority services herein described, Actalis conforms to version 1.1 of the Baseline Re-

quirements for the Issuance and Management of Publicly-Trusted Certificates published at

http://www.cabforum.org. In the event of any inconsistency between this document and those Requirements,

those Requirements take precedence over this document.

Furthermore, with regard to certificate types denoted by “EV” (see section 1.2), Actalis conforms to version 1.3

of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates pub-

lished at http://www.cabforum.org. In the event of any inconsistency between this document and those Guide-

lines, those Guidelines take precedence over this document.

1.2 Document Identification

This document is the Certification Practice Statement (CPS) applying to SSL Server and Code Signing certifi-

cates issued by Actalis S.p.A. Version and time of last revision are indicated on the first page. This document is

published on Actalis’ web site in two languages: Italian and English. In the event of any inconsistency between

the two versions, the Italian version takes precedence.

1.3 Participants to Public Key Infrastructure (PKI)

1.3.1 Certification Authority

The Certification Authority (CA) is the trusted third party who issues the certificates and signs them with its

own private key (CA key). Furthermore, the CA manages the status of the certificates.

The Actalis PKI (Public Key Infrastructure) that the SSL Server and Code Signing certificate issuance and man-

agement service is based upon is a two-level hierarchy, as shown in the following diagram:

http://www.actalis.it/



Root CA

Sub CA 1 Sub CA 2 Sub CA ...

The Root CA is used for issuing Sub CA certificates and related CRLs only, and is kept off-line when not in use,

whereas end-entity certificates are issued by Sub CAs.

Within the framework of the service described in this document, both CA roles (Root CA and Sub CA) are played

by Actalis S.p.A. (hereinafter referred to as “Actalis”), and identified as follows:

Company name: Actalis S.p.A.

Registered Office: Via dell’Aprica, 18 – 20158 Milan, Italy

Legal representative: Simone Braccagni (Chief Executive Officer)

VAT Reg. No. and Tax Code: 03358520967

Telephone (switchboard): +39 02 68825.1

DUNS number: 440-489-735

ISO Object Identifier (OID): 1.3.159

Company web site: http://www.actalis.it

Company e-mail address: [email protected]

1.3.1.1 Root Certification Authority

The Root CA is run by Actalis S.p.A. (see section 1.3.1).

1.3.1.2 Subordinate Certification Authority

There currently exists only one Sub CA, run by Actalis S.p.A. (see section 1.3.1).

The feasibility and opportunity of activating additional Sub CAs, run by other organizations, will be evaluated

later on, taking into account the requirements and constraints imposed by the applicable laws, business prac-

tices, and security policies (including those enforced by browser vendors).

1.3.2 Registration Authorities

The Registration Authority (RA) is a person, structure or organization that is responsible for:

collection and validation of certification requests and certificate management requests;

registration of the applicant and organization to which the same belongs;

authorization of issuance, by the CA, of the certificate requested;

For certificates of class EV (Extended Validation), the RA activities are performed by Actalis only.


mailto:[email protected]



For certificates of class OV (Organization Validated) and DV (Domain Validated), RA activities can be carried out

by the Customer as an “Enterprise RA”, if the conditions are met, limited to Internet domains controlled by the

Subscriber.

1.3.3 Subscribers

Certificate Owners or Subscribers are organizations or agencies requesting an SSL Server certificate or Code

Signing certificate and holding the corresponding private key. In particular, with reference to §7.2 of [EVCG],

Actalis issues certificates to following types of organizations:

Private Organization

Government Entity

In this CPS, the term “Owner” refers to the entity named “Subject” or “Subscriber” in [BR] and [EVCG].

In all cases the certificate Owner shall be an organization, not a natural person.

The contract with the CA is normally stipulated by the subscriber as the customer. Nonetheless the customer

(the party which pays the certificate and its subsequent management by CA) may be acting on behalf of the

Subject, a circumstance which must be demonstrated upon application (see §3.2.2).

1.3.4 Relying parties

Relying Parties are recipients of a certificate who act on reliance on the information contained in the certifi-

cate. In the case of an SSL Server certificate, these are the users of the relevant web site. For Code Signing cer-

tificates, these are users of the signed software.

1.4 Use of certificates

The SSL Server certificate is used to activate the TLS/SSL protocol on one or more web sites.

The Code Signing certificate is used for the digital signature of software (executable code).

Any other use of the certificates issued by Actalis in accordance with this CPS is strictly prohibited and may re-

sult, as soon as Actalis gets aware of it, the revocation of the certificate.

It is assumed that the subscriber possesses the competence and tools required to request, install and use the

certificate. At any rate, Actalis can provide all the necessary assistance as consultancy.

The following table shows the classes and policies of certificates issued under this CPS, and the applicable CAB

Forum requirements. Each policy is identified by a specific OID (Object Identifier) under the 1.3.159 arc:

Class Certificate policy OID CABF reqs.

EV SSL Server EV (Extended Validation) 1.3.159.1.17.1 [BR], [EVCG]

EV Code Signing EV (Extended Validation) 1.3.159.1.18.1 [BR], [EVCG]

OV SSL Server Wildcard OV (Organization Validated) 1.3.159.1.19.1 [BR]

OV SSL Server OV (Organization Validated) 1.3.159.1.20.1 [BR]

OV Code Signing OV (Organization Validated) 1.3.159.1.21.1 [BR]

DV SSL Server DV (Domain Validated) 1.3.159.1.22.1 [BR]

DV SSL Server Wildcard DV (Domain Validated) 1.3.159.1.23.1 [BR]



The OID that identifies the certificate policy is contained in the CertificatePolicies certificate extension, as de-

tailed un chapter 7.

1.5 Administration of CPS

This CPS is developed, reviewed, published and updated by Actalis S.p.A.

For further information or explanations about this CPS, please write e-mail to the following address: cps-

[email protected].

This CPS and the certificate policies (CP) herein described are approved by Actalis’ top management, on rec-

ommendation by the CPS maintainer, after checking with all the company departments involved in the CA ser-

vice. Actalis periodically reviews its certification processes including the responsibility for maintaining this CPS,

also taking into account §8.1 of the ETSI TS 101 042 specification [POLREQ].

1.6 Definitions and acronyms

AgID Agenzia per l’Italia Digitale (Agency for a Digital Italy)

ARL Authority Revocation List

CA Certification Authority

CCIAA Chamber of Commerce, Industry, Crafts and Agriculture

CNAME Canonical Name

CNIPA Italian Authority for Informatics in Public Administration, former name of DigitPA

CPS Certification Practice Statement

CRL Certificate Revocation List

CSR Certificate Signing Request

DigitPA New name of CNIPA after Decree n.177 of December 1st

, 2009.

DN Distinguished Name

DPC (CED) Data Processing Centre

DV Domain (Control Validated)

EV Extended Validation

FIPS Federal Information Processing Standard

FQDN Fully Qualified Domain Name

HSM Hardware Security Module

HTTP Hyper-Text Transfer Protocol

I&A Identification and Authentication

IDN Internationalized Domain Name

ISO International Standards Organization

LDAP Lightweight Directory Access Protocol

OCSP On-line Certificate Status Protocol

OID Object Identifier

OV Organization Validated

PDF Portable Document Format





PKI Public Key Infrastructure

RA Registration Authority

SAN SubjectAlternativeNames (certificate extension)

SSL Secure Sockets Layer

TLS Transport Layer Security

UPS Uninterruptible Power Supply

VMD Video Motion Detection

1.7 List of references

[DLGS196] Legislative Decree n.196 of 30 June 2003 “Personal data protection code”, published in the Supplemento Ordinario n.123 of the Gazzetta Ufficiale n.174 of 29 July 2003.

[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. (http://www.ietf.org/rfc/rfc2251.txt)

[RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", RFC 2314, March 1998. (http://www.ietf.org/rfc/rfc2314.txt)

[RFC2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. Adams, "Online Certificate Status Protocal - OCSP", June 1999. (http://www.ietf.org/rfc/rfc2560.txt)

[RFC2616] [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol, HTTP/1.1", RFC 2616, June 1999. (http://www.ietf.org/rfc/rfc2616.txt)

[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. (http://www.ietf.org/rfc/rfc2818.txt)

[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003. (http://www.ietf.org/rfc/rfc3647.txt)

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. (http://www.ietf.org/rfc/rfc5280.txt)

[X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks. (http://www.iso.ch)

[POLREQ] ETSI TS 101 042: Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates, v2.2.1 (2011-12).

[BR] CA/Browser Forum, “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates”, Version 1.1.

[EVCG] CA/Browser Forum, “Guidelines For The Issuance And Management Of Extended Validation Certificates”, Version 1.3.

http://www.ietf.org/rfc/rfc2251.txt







http://www.iso.ch/



2 Publications and repository

The term “repository” refers to a combination of on-line archives or registers containing information of public

interest regarding the issuance and management of certificates described in this CPS.

2.1 Repository management

The Actalis repository consists of:

CA web sites (http://www.actalis.it and other Actalis websites therein referred to)

CA directory server (ldap://ldap03.actalis.it)

Note: for load balancing reasons, the directory service is distributed on several servers with different address-

es, thus the hostname included in a particular certificates maybe different from ldap03; it will, however, be a

CNAME of this latter.

The CA manages the repository and is directly responsible for the same.

2.2 Published information

As a minimum, the CA publishes the following documentation on its own web site:

Certification Practice Statement (CPS)

Root CA and SubCA certificates

Terms & Conditions of the service

maximum fees charged for the service

request forms

Furthermore, the CA publishes CRLs on its own directory server.

For further information about the CRL refer to section 4.10.

2.3 Time and frequency of publications

The CPS and associated documentation are published in PDF format on the CA web site each time they are up-

dated.

This CPS is reviewed and, if necessary, updated at least every year.

For further information about the CRL refer to section 4.10.

2.4 Access control

Anyone can freely access the repository in read-only mode.

Access to the repository for the publication of new and updated information is only possible from work stations

directly connected to the repository local network, subject to authentication.


ldap://ldap03.actalis.it/



3 Identification and Authentication (I&A)

The I&A procedures followed by Actalis comply with CAB Forum requirements. In particular, for all classes of

certificates issued under this CPS, the CA peforms at least the mandatory checks provided in the Baseline Re-

quirements for the Issuance and Management of Publicly-Trusted Certificates [BR]. In addition, for certificates

of class EV, the CA also performs the additional checks required by the Guidelines For The Issuance And Man-

agement Of Extended Validation Certificates [EVCG].

3.1 Naming rules

The Subject field of the certificate, if present (according to certificate class), must contain easily understanda-

ble information allowing the identification of the certificate holder (organization). Aliases, or names other than

the certificate owner’s full legal name, are not allowed.

Names which violate the intellectual property rights of others are not allowed into certificates. Actalis shall not

be involved in any controversy whatsoever regarding the ownership of domain names, commercial names,

commercial trademarks or services. Actalis reserves the right to reject the certificate application (or revoke an

already issued certificate) in case of such a controversy.

3.1.1 For all certificate classes

For all certificate classes, the following rules apply:

The commonName (OID 2.5.4.3) component of the Subject field:

– for an SSL Server certificate, must contain one single IP address or Fully Qualified Domain Name

(FQDN) among those contained in the SAN extension;

– for a Code Signing certificate, may contain any string chosen by requestor, provided

that it is not misleading about the certificate owner’s identity or about the certificate purpose. In

any case, it must not be a hostname (qualified or not). A valid example is “ACME Code Signing”.

The organizationName (OID 2.5.4.10) component of the Subject field, if present (according to

certificate class), must contain the full legal name of the certificate owner (it must be an organization;

it cannot be a natural person); this name must be unique, that is, it must not lead to ambiguity. For an

SSL Server certificate, it must be the organization that controls the servers included in the certificate;

therefore, it will generally be the owner (registrant) of the Internet domains included in the certificate,

or its parent organization (i.e. holding), or another entity that has formally been charged of managing

those servers and/or domains on behalf of their owner.

The SubjectAlternativeNames (SAN) extension, always included in an SSL Server certificate, must

contain at least one item. Each of the items in this extension must be an IP address or an FQDN of a

server under control of the certificate owner.

Note: internal IP address and domains are deprecated by CAB Forum and will not be included in certificates having

an expiry date past November 1st

, 2015. At any rate, by October 1st

, 2016, the CA will revoke all certificates having

an internal IP address or domain within.

The optional organizationalUnitName (OID 2.5.4.11) component of the Subject field may contain any

string at the requestor’s discretion, provided that it does not mislead Relying Parties about the identity

of the certificate owner. More generally, potentially misleading information shall not be included in

the certificate.



The localityName (OID 2.5.4.7) component of the Subject field, if present (according to certificate

class), must contain the name of the locality (e.g. city) where the certificate owner’s registered office is

located.

The stateOrProvinceName (OID 2.5.4.8) component of the Subject field, if present (according to

certificate class), must contain the name of the Province (for Italian organizations) or Region/State (for

foreign organizations) where the certificate owner’s registered office is located.

The countryName (OID 2.5.4.6) component of the Subject field, if present (according to certificate

class), must contain the ISO 3166 two-letter code (e.g. “IT”) of the country where the certificate

owner’s registered office is located.

3.1.2 For EV-class certificates

In addition to the above rules, for EV-class certificates the following rules also apply:

the businessCategory (OID 2.5.4.15) component of the Subject field must contain the organization

type (either “Private Organization” or “Government Entity”);

the serialNumber (OID 2.5.4.5) component of the Subject field must contain the VAT Number (“Partita

IVA” for Italian organizations), or other official registration number (for foreign organizations), of the

certificate owner;

the jurisdictionOfIncorporationCountryName (OID 1.3.6.1.4.1.311.60.2.1.3) component of the Subject

field must contain the two-letter ISO 3166 code of the country where the organization (i.e. certificate

owner) was registered or incorporated;

the streetAddress (OID 2.5.4.9) component of the Subject field must contain the address (e.g. street

name and building number) of the certificate owner’s registered office.

3.1.3 For DV-class certificates

In certificates of class DV, the Subject field only contains:

the commonName component, according to section 3.1.1;

the organizationalUnitName with a fixed value of “Domain Validated by Actalis S.p.A.”

3.2 Initial identity validation

3.2.1 Proving possession of private key

The proof-of-possession, by the applicant, of the private key corresponding to the requested certificate is

based on the cryptographic verification of the CSR (Certificate Signing Request) sent to the CA. In fact the appli-

cant must send its own public key to the CA in the form of a CSR in PKCS#10 format [RFC2314]. The CA shall

verify that the digital signature in the CSR is valid.

Transmission of the CSR to the CA is normally done over the web or via electronic mail.

3.2.2 Authentication of organization identity

Authentication of the identity of the applicant organization, not applicable to DV-class certificates, includes in

any case a lookup in the relevant CCIAA (Chamber of Commerce, Industry, Crafts and Agriculture) database, for

private organizations, or in the relevant official index of public administrations, for government entities. The

name of the organization declared by the applicant must correspond with the name resulting from such



lookup. In case of mismatch, unless the applicant can provide a convincing explanation, the certificate applica-

tion shall be rejected. The information gathered by the CA include at least (where applicable):

actual existence and status of the organization

full legal name of the organization

VAT code (and # of registration at a chamber of commerce, for private organizations) or an equivalent

government-issued identification code

address of head office and operation sites

Should the CA not be able to collect such information by itself, the applicant will be required to provide it to

the CA in a reliable form (such as e.g. the official report issued by a chamber of commerce).

3.2.3 Authentication of individual identity

Verification of individual identities, when required (according to certificate class), is done by one of the follow-

ing methods:

face-to-face; examination, by a CA operator, of an government-issued personal identity document,

when applicable;

by telephone: a CA operator contacts the Applicant (person) over the telephone, through the

Subscriber organization’s switchboard;

by digital signature: the certificate application form is digitally signed by a qualified electronic signature

(according to EU norms), so the signer’s identity can be extracted from his/her qualified certificate

(which must be valid at the time of verification by the CA).

The CA reserves the right to perform further verifications in order to validate individual identities.

3.3 Further verifications by the CA

In case of negative or uncertain results of the verification steps described below, if the applicant is not able or

willing to provide the necessary evidence to the CA, the certificate application is rejected. The CA reserves the

right to carry out further investigations and checks, in addition to those described below, in ways not prede-

termined.

3.3.1 For all classes of SSL Server certificates

For SSL Server certificates, the CA verifies that all FQDNs and IP address to be included in the certificate are

under the control of the Applicant organization, or his parent organization. These checks are carried out by dif-

ferent methods, depending on the case and the certificate class:

by means of WHOIS queries (+ reverse DNS lookups for IP addresses) to reliable DNS information

sources.

by querying the relevant DNS Registrars or governmental domain registration agencies, as appropriate;

by communicating with the domain administrator via e-mail, using an e-mail address obtainned by pre-

pending a “admin”, “administrator”, “webmaster”, “hostmaster”, or “postmaster” to the domain name

(this latter is obtained by pruning zero or more components from the requested FQDN).

Should one or more of those FQDNs and/or IP addresses be managed by an entity other than the Applicant or

their parent organization, the Applicant is required to provide evidence to the CA that they have been formally

delegated by the domains’ owner to manage those domains and/or IP addresses.



3.3.1.1 Internationalized Domain Names (IDN)

As of the date of revision of this CPS, Internationalized Domain Names (IDN) are not allowed: all FQDNs to be

inserted in the certificate must therefore be comprised of ASCII characters only.

3.3.2 For EV-class certificates

For private organizations, the CA also collects and evaluates the following information:

address of registered office

starting date of organization’s activity

business purpose (objects)

board members

proprietor(s) or shareholders

transfers of property or shares

powers and representatives

protests, insolvency or other negative facts

For government entities, the CA also collects and evaluates the following information:

address of main office

names and roles of top managers

In both cases, the CA verifies that the certificate application was authorized by a manager of the applicant with

adequate powers of attorney.

The CA also verifies that all the address components (country, stateOrProvince, locality, streetAddress) to be

included in the certificate match the address where the registered office of the applicant organization is actual-

ly located.

All the above checks are carried out by querying the relevant chamber of commerce database (for private or-

ganizations) or the appropriate governmental database (for governmental entities).

If the applicant organizations is found to have been in existence for less than 3 years, the CA checks that the

applicant organization possesses a bank account. To that purpose, the applicant organization must provide to

the CA a letter of bank reference, dated and signed by the bank, on headed paper.

If the CA finds problematic situations (e.g. bankruptcy proceedings, disputes, insolvency, etc.) regarding the

applicant organization or the person who authorized the certificate application, the procedure is suspended

and the case is brought to the attention of the Financial Officer and of the Head of Security of the CA, for fur-

ther evaluation.

3.4 Information not verified by the CA

The CA does not verify the electronic mail address indicated in the application form.

In general, the CA does not verify the correctness of any information received from the applicant which is not

intended to be used in security-sensitive fields of the certificate and is not necessary for the issuance and sub-

sequent management (suspension, re-activation, revocation) of the certificate.



3.5 I&A for renewal applications

The renewal process is similar to the first issuance process. It consists in the generation of a new pair of keys,

by the subscriber, to replace the expired pair and a request to the CA for a new certificate. The same identifica-

tion and authentication processes (I&A) as used for first issuance are also followed for the renewal.

3.6 I&A for requests to suspend or revoke

The methods for identification and authentication of the requests to suspend or revoke a certificate depend on

the channel which is used for the request:

in order to submit suspension or revocation requests through the CA portal, it is necessary to login to

the portal by means of a user-id and password (these credentials are sent to the subscriber via e-mail);

in the case of revocation requests sent to the CA on paper, the procedures described at §3.2.3 shall be

followed.

4 Certificate management operational requirements

4.1 Certificate application

The certificate application is done by filling out, signing and sending to the CA (e.g. via e-mail) a suitable appli-

cation form, to be found on the CA portal, together with the necessary annexes. An on-line equivalent of such

form is made available to Enterprise RAs.

The form must be signed by a legal representative (or other person with sufficient authority) of the requesting

organization.

The certificate application shall at least include the following information:

details of requesting organization

personal and contact details (e-mail, telephone) of applicant

personal and contact details (e-mail, telephone) of technical reference(s)

hostnames to be included in the certificate (for SSL Server certificates)

certificate Subject details proposed by applicant

The certificate application form incorporates by reference the Terms & Conditions of the CA service offered by

Actalis; therefore, by undersigning the certificate application form, the requestor also confirms his/her accep-

tance of the Terms & Conditions. Prior to signing the form, the requestor can evaluate every aspects of Actalis’

CA service by reading the documentation published on the web site http://www.actalis.it, in the section devot-

ed to SSL Server and Code Signing certificates.

The certificate application form must be accompanied or followed by a suitable Certificate Signing Request

(CSR), to be sent to the CA via email to the address provided in the application form.

The CSR is normally generated by the applicant organization by their own means (see also section 6.1.3), unless

assistance by Actalis has previously been requested.



It is also possible to apply for a “wildcard” SSL Server certificate (i.e., valid for all web sites belonging to a spe-

cific domain) or a multi-SAN SSL Server certificate (wherein two or more SAN values are present specifying sev-

eral hostnames and/or domain names for which the same certificate will be used). In such cases, the same I&A

procedures apply: the CA always checks that the requestor actually owns or controls the domains and/or IP ad-

dresses to be included in the certificate and that the requestor is an existing organization based on latest

chamber of commerce records or other applicable reliable source of information.

Wildcard and multi-SAN SSL Server certificates are subject to different fees than those for plain certificates (i.e.

single web site). For further information please contact Actalis’ sales department.

The maximum number of SAN values allowed in an SSL Server certificate is 100.

4.2 Application processing

The procedure for certificate issuance enforces a “dual control” requirement, in that it always requires

two different operators to be completed:

RA operator (RAO)

CA operator (CAO)

Upon receipt of a certificate application form, the RAO:

carries out all the verifications described in §0;

performs the additional verifications described in §3.3;

registers the applicant and the request details into the CA database;

verify that the identification data contained in the CSR are coherent with that supplied in the

application form;

sends to the requestor, via email, the authentication credentials needed to login to the CA portal, for

the possible submission of suspension, re-activation or revocation requests.

Registration of the applicant entails storing, into the CA database, of the identification and contact data (tele-

phone, e-mail) of the applicant organization and the person requesting the certificate (e.g. the legal repre-

sentative or another executive with power of signature), plus the details of the certificate request.

For performing the operations listed above, the RAO logs on to Actalis’ CA system by means of a strong (i.e.

two-factor) authentication.

4.3 Issue of certificates

If the verifications above are successful, the CAO:

verifies that the CSR matches the request data stored into the CA database;

checks that the CSR is well-coded and does not contain unexpected data;

checks the possession, by the requestor, of the private key matching the CSR (see §3.2.1);

The above verifications are done automatically, by Actalis’ CA system, on command of the CAO.

If all the above checks are successful, the CAO generates the certificate, stores it into the CA database, and

eventually sends to the subscriber via e-mail:

the subscriber certificate as an attachment;



the certificate of issuing CA (that is, the Subordinate CA: see §1.3.1.2), or a URL to download it from

the CA portal;

possible ancillary information.

At this point, if the certificate has not already been paid for, the CA issues the invoice and sends it this to the

customer.

4.4 Certificate acceptance

The certificate is intended as accepted after 30 days from the date of delivery, as attested by the date of the

electronic mail message sent to the subscriber by the CA, if the absence of any notice to the contrary from the

subscriber.

Public use of the certificate (i.e. its installation on a website with public access, publication on a public websites

of executable code signed by that certificate), even if temporary, shall in any case imply acceptance of the cer-

tificate by the subscriber.

In the event that the certificate is issued with incorrect information in it due to incorrect completion of the ap-

plication form by the requestor, the certificate must nonetheless be paid for.

4.5 Use of key pair and certificate

The subscriber shall use the private key:

(Code Signing certificates) to digitally sign proprietary executable code (e.g. Java applets, dynamic

libraries, etc.) and/or code for which the same is responsible;

(SSL Server certificates) to activate the TLS/SSL protocol on its own web site, thereby allowing server

authentication and encryption of the transactions with web browsers.

The relying parties shall use the certificate:

(Code Signing certificates) to verify the integrity and origin of the executable code;

(SSL Server certificates) to verify the identity of a web site and the organization which manages the

site, as well as to exchange the “session key” with the web server in a safe manner.

See also paragraph 1.4.

4.6 Certificate renewal

The certificate has an expiry date beyond which it is no longer valid. The reason for which the certificate has a

limited duration is that the security of a pair of encryption keys could decrease over time or even be compro-

mised, due to the effect of cryptanalytic techniques and attacks by criminals. For these reasons Actalis does not

renew a certificate, unless the subscriber generates a new key pair. Apart from this, the renewal process is the

same as the first issue process.

4.7 Key re-generation

In the case when the subscriber decides to use a new key, the same shall request a corresponding new certifi-

cate.



4.8 Certificate modification

Since the certificate is signed by the issuing CA, it cannot be “modified”. Thus, to solve a possible certificate

generation problem, it is necessary to issue a new one (and revoke the incorrect one for obvious security rea-

sons).

In the case when the issued certificate contains incorrect information due to mistakes by the CA, the incorrect

certificate shall be revoked and a correct one will be promptly issued without additional costs for the client and

without asking the client for additional information.

In the case when the issued certificate contains incorrect information due to mistakes by the applicant (i.e. in-

correct filling-out of one or more fields of the application form), the incorrect certificate shall be revoked.

4.9 Certificate suspension and revocation

The suspension of the certificate determines a temporary suspension of the validity of a certificate, starting

from a given moment in time (date/time). Once a certificate has been suspended, it can be re-activated at any

time.

Revocation determines the premature termination of the validity of a certificate, starting from a given moment

in time (date/time). Revocation of a certificate is irreversible and not retroactive.

Implementation of the suspension or revocation consists in the generation and publication of a new CRL (Cer-

tificate Revocation List) which includes the serial number of the suspended or revoked certificate. The CRL is

accessible to anyone needing to verify the certificate status (refer to section 4.10).

Re-activation consists in the generation and publication of a new CRL in which the serial number of the previ-

ously suspended certificate does not appear.

4.9.1 Reasons for suspension

The conditions which could cause a suspension are as follows:

suspected compromise of private key;

temporary interruption of the use of the certificate by the client;

breaches of contract by the client (e.g. failure to pay).

4.9.2 Request for suspension

Suspension can be requested by the client and/or subscriber of the certificate or by the CA.

Under certain circumstances the subscriber shall be obliged to request suspension of the certificate (refer to

paragraph 9.5.3).

Suspension can be performed directly by the CA when the same becomes aware of conditions which could

compromise the reliability of the certificate or which constitute contractual non-fulfilments by the client.

4.9.3 Suspension procedure

Suspension can be requested by the subscriber on-line (refer to paragraph 4.9.6).

Following a period of 15 days after suspension the certificate will be re-activated automatically.



The certificate may also be re-activated by the user, at any moment in time, via the CA services web portal,

subject to authentication.

4.9.4 Certificate revocation

The conditions which may lead to a revocation are:

a court order;

the subscriber requests in writing that the CA revoke the certificate;

the subscriber notifies the CA that the original certificate request was not authorized and does not

retroactively grant authorization;

the CA obtains evidence that the subscriber’s private key (corresponding to the public key in the

certificate) has suffered a key compromise, or that the certificate has otherwise been misused;

the CA is made aware that the subscriber has violated one or more of its material obligations under the

Terms & Conditions of the service and/or this CPS;

the CA is made aware that use of a FQDN or IP address in the certificate is no longer legally permitted

(e.g. a court or arbitrator has revoked a domain name registrant’s right to use the domain name, the

domain name registrant has failed to renew the domain name, etc.);

the CA is made aware that a wildcard certificate has been used to authenticate a fraudulently

misleading subordinate FQDN;

the CA is made aware of a material change in the information contained in the certificate;

the CA is made aware that the certificate was not issued in accordance with this CPS;

the CA determines that any of the information appearing in the certificate is inaccurate or misleading;

the CA ceases operations for any reason and has not made arrangements for another CA to provide

revocation support for the certificate;

the CA’s right to issue certificates under CAB Forum’s Baseline Requirements [BR] expires or

is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP

repository;

the CA is made aware of a possible compromise of the private key of the subordinate CA used for

issuing the certificate;

the technical content or format of the certificate presents an unacceptable risk to application software

suppliers or relying parties (e.g. the CA/Browser Forum might determine that a deprecated

cryptographic/signature algorithm or key size presents an unacceptable risk and that such certificates

should be revoked and replaced by CAs within a given period of time);

the CA is made aware that the subscriber organization ceased its activity;

the CA is made aware that the certificate has an incorrect profile (e.g. incorrect values in some of the

certificate’s extensions, according to [BR] and/or [EVCG] depending on certificate type);

breach of contract by the client (e.g. failure to pay).

In all the above circumstances, the CA shall revoke the certificate within 24 hours.

Furthermore, if the CA is made aware that the certificate is being used by the owner for any kind of criminal

activity (e.g. "phishing" attacks, "man-in-the-middle" attacks, malware distribution, etc.), the CA shall immedi-



ately revoke the certificate, without notice. Similarly, in the case where the CA discovers that the certificate

was wrongly issued with CA = TRUE in its KeyUsage extension.

4.9.5 Revocation request

Revocation can be requested by (depending on circumstances);

the subscriber (certificate owner);

the issuing Certificate Authority;

the court of law.

Furthermore, anybody may inform the CA of facts that may lead the CA, depending on circumstances, to decide

for revocation of the certificate.

Under certain circumstances the subscriber must request revocation of the certificate (see also §9.5.3).

4.9.6 Procedure for suspension or revocation

Requests for suspension or revocation may be submitted to the CA through the Actalis CA services web portal

(whose address is found on www.actalis.it). To access those functions it is necessary for the subscriber to login

to the portal using the credentials provided to them by the CA upon certificate issuance.

As an alternative, for revocation it is possible to fill out a request form on paper, signed by the subscriber or-

ganization’s representative. The signed form may then be delivered to the RA by hand or sent directly to the CA

via fax, ordinary mail, or electronic mail.

Regardless of whom requested the certificate suspension or revocation, the CA shall inform the subscriber

about the suspension or revocation via an e-mail message sent to the address of the “technical contact” indi-

cated in the application form.

Revocation requests submitted to the CA in paper form or via fax/email are processed within 24 hours in 90%

of cases, on working days only.

4.9.7 Frequency of issue of CRL

See paragraph 4.10.1.

4.10 Certificate status information

In general, the status of the certificates (active, suspended, revoked) is made available to all interested parties

through the publication of the Certificate Revocation List (CRL) in the format defined in the specification

[RFC5280].

For end-user certificates, an on-line certificate status checking service is also available, based on OCSP (On-line

Certificate Status Protocol) in compliance with the specification [RFC2560].

4.10.1 Operational characteristics

The CRL can be accessed in two different ways:

via LDAP protocol [RFC2251] on server ldap03.actalis.it

via HTTP protocol [RFC2616] on server crl03.actalis.it


ldap://ldap03.actalis.it/

http://crl03.actalis.it/



The LDAP and HTTP complete addresses of the CRL, listed below, are inserted in the CRLDistributionPoints ex-

tension of the certificate:

ldap://ldap03.actalis.it/cn=Actalis Authentication CA GN,o=Actalis

S.p.A./03358520967,c=IT?certificateRevocationList;binary

http://crl03.actalis.it/Repository/AUTH-GN/getLastCRL

…where N in GN stands for the SubCA generation number.

Note: for load balancing reasons, the directory service is distributed on several servers with different address-

es, thus the hostname included in a particular certificates maybe different from ldap03 or crl03 (for LDAP and

HTTP, respectively); it will, however, be a CNAME of this latter.

The CRL is re-generated and re-published:

at least every 6 hours, even in the absence of new suspensions or revocations;

following each new suspension or revocation.

The OCSP server address, following, is inserted in the AuthorityInformationAccess certificate extension:

http://ocsp03.actalis.it/VA/AUTH-GN

Note: for load balancing reasons, the OSCP service is distributed on several servers with different addresses,

thus the hostname included in a particular certificates maybe different from ocsp03; it will, however, be a

CNAME of this latter.

The CRL and OCSP services can be freely accessed by anyone.

The ARL, namely the list of revoked SubCA certificates, is re-generated and re-published:

at least every 3 months, even in the absence of new suspensions or revocations;

following each new suspension or revocation.

4.10.2 Service availability

Access to the CRL and OCSP service is continuously available (24 x 7), except for scheduled maintenance of the

servers or in the case of faults. See also §9.16.

4.11 Contract termination

The service contract stipulated between the CA and client is intended as terminated:

at the natural expiry date of the certificate, or…

at the date when the certificate has been revoked (refer to section 4.9).

4.12 Key escrow and recovery

The term “key escrow” is intended as the consignation of the CA key pair to a trusted third party (e.g. notary

public). Within the framework of the service provided by Actalis in accordance with this CPS, the escrowing of

the CA key is not contemplated.

However, key recovery of the CA key is provided, in the case of unintentional cancellation or fault in the HSM.

In order to allow key recovery, the CA keeps a backup CA key pair (refer to paragraph 6.8).



4.13 Certificate problem reporting

Actalis makes available to all interested parties (Owners, Relying Parties, vendors of software such as web

browsers, law enforcement, etc.) two communication channels through which certificate problems can be re-

ported to the CA at any time (24x7).

the mailbox [email protected], which the CA commits to timely read during working hours only

(9 AM to 5 PM on Italian working days);

the telephone number +39-02-68825.576, at which Actalis commits to answer at all times (24x7x365).

Regardless of the communication channel used, the problem reporter must provide at least the following in-

formation, or the communication will be ignored:

his/her full name;

his/her phone number;

description of the alleged problem;

enough information to identify the certificate in question, such as:

– for an SSL Server certificate: either the address of the web site where the certificate is installed,

or the certificate hostname, starting validity date, and serial number;

– for a Code Signing certificate: commonName (CN), starting validity date, and serial number.

Such communications may be made in Italian or English; other languages are not handled.

The CA is committed to take charge of proper communications within 24 hours, start investigating the reported

problem, and take the necessary measures, depending on the problem severity. The priority assigned to the

problem will depend on:

the nature of the alleged problem;

the identity of the reporter (reports received by a Court or law enforcement agents will be handled

with higher priority than other messages);

the law and/or regulations relevant for the alleged problem (e.g. reports of illegal acts will be handled

with higher priority than other messages).

If the reported problem does exist, the CA will decide on a case by case basis the measures to be taken (e.g.

revocation of the certificate) and will notify the reporter by e-mail.

Note: those who send unwanted messages (spam) will be prosecuted according to applicable laws.

5 Physical and operational security controls

The technological infrastructure, operating procedures, physical and logical security controls and personnel re-

sponsible for providing the service described in this CPS are the same as those used within the Actalis service

for issuing qualified certificates (according to EU directive on electronic signatures).



5.1 Physical security

All computer systems used for the provision of the certification services herein described, with the exception of

the server containing the evidence of registration (see below), are housed in the Actalis data center Actalis lo-

cated in Arezzo, Via Gobetti 96.

For the management of its CA infrastructure, Actalis makes use of the data center services provided by its hold-

ing company, Aruba S.p.A., who takes responsibility for the housing, Internet connectivity, and physical security

of all Actalis’ systems. In particular, Aruba is committed to guarantee the following to Actalis:

a physical access control system, so that access to the building is only possible for those who need,

after checking in at the reception, and access to data rooms is only possible for authorized personnel

holding a suitable badge and the corresponding PIN;

passive and active intrusion detection systems, such as grids, bullet-proof windows, security doors,

motorized gates, TVCC and VMD;

a fire protection system, compliant with applicable laws and technical standards, including smoke and

fire detectors placed all over the building;

a power supply system fully redundant at all levels (transformers, power centers, generators, UPS’s,

distribution panels, etc.) so that electrical power supply is guaranteed under all foreseeable conditions;

a ventilation and air conditioning system (HVAC) which guarantees optimal climatic conditions for the

smooth operation of all servers housed in the data center;

a Network Operation Center (NOC), manned h24 for 365 days/year by qualified personnel, ensuring

constant monitoring of infrastructure and services and timely intervention in case of need;

redundant Internet connectivity, with a capacity of at least twice the minimum necessary;

ISO 27001 certification of the service provided.

At the Actalis offices of Milan, Via dell'Aprica 18, there is a server on which all the evidence related to the issu-

ance of certificate subscribers, as well as the certificates themselves and off-line revocation requests, are

stored in electronic form.

5.2 Procedural controls

Actalis maintains a Security Plan which analyses the assets, the threats they are exposed to, and describes the

technical and organizational controls in place, aimed at assuring an adequate level of security for the opera-

tions. The risk assessment is reviewed at least yearly.

Actalis’ operational procedures are documented under the company’s Quality Management System, certified in

accordance with the ISO 9001 standard.

5.3 Personnel controls

Personnel involved in the service have at least 5 years of working experience in the definition, development

and management of PKI services and have been adequately trained on the procedures and tools to be used

during the various operational phases.

5.4 Event logging

The main events relevant to the certificate lifecycle operations, including the requests for certification, suspen-

sion or revocation etc., are registered on paper or in electronic form. Furthermore, events like the following



are also recorded: logical access to the certificate management system, operations carried out by Actalis per-

sonnel, presence of visitors at areas where certification activities are performed etc.

For each event, information is logged about the type, date and time of occurrence and, if available, other in-

formation useful to identify those involved in the event and the outcome of the operations.

All that information constitutes the audit log. The files that the audit log is comprised of are periodically trans-

ferred to permanent archive media.

The CA keeps the audit log for at least 7 years.

5.5 Data retention and archival

The CA keeps the following information related to the certificate issuing and management processes:

certificates issuing requests

documentation supplied by applicants

CSR (Certificate Signing Request) supplied by applicants

personal details of the applicants and subscribers (when the two are different)

results of verifications performed by the CA (e.g. chamber of commerce enquiries, WHOIS records,

etc.)

suspension and revocation requests

all certificates issued

All the above data are retained for at least 7 years past the certificates’ expiration dates.

5.6 Renewal of CA key

5.6.1 Root CA

No stipulation.

5.6.2 Sub CA

At least 3 years before the end of the validity of the current certification key (Sub CA key), a new Sub CA key

pair will be generated and distributed to end users with the methods described in section 6.2.1. From that

moment on, end user certificates and related CRLs shall be signed with the new Sub CA key.

5.7 Backup copy

A backup copy of data, applications, and any other file necessary for a complete recovery of the service is per-

formed on a daily basis.

5.8 Compromise and disaster recovery

The term “disaster” is referred to a damaging event, the consequences of which determine the unavailability of

the service under normal conditions, such as the failure or unavailability or the facilities (e.g. computer sys-

tems, HSMs, wiring, data rooms, power supply, etc.) that are necessary for providing the certification services.

Following a disaster, special procedures shall be applied for the recovery of the certification services. Those

procedures are documented in Actalis’ security plan, viewable at Actalis’ head office on subscriber request.



In the event that one of the algorithms (or their parameters) used for issuing and using certificates gets com-

promised, the CA shall:

inform all subscribers of certificates issued under this CPS, and all relying parties with which the CA has

made arrangements in this regard;

promptly publish on its web site a prominent warning notice;

revoke all certificates that became unreliable because of the event;

suspend the CA service (it will be resumed after having solved the problem, if possible, by changing the

compromised algorithms, or their parameters, and possibly generating a new SubCA and/or RootCA

key).

The CA shall proceed in a similar manner in the event of a CA key compromise, e.g. in case of loss of confidenti-

ality (undue disclosure to unauthorized third parties) of one of the CA private keys used for issuing certificates

under this CPS. If that is the consequence of a security incident, the relevant handling procedure will be started

and all interested parties will be informed.

5.9 Cessation of the CA

In the event that the CA intends to cease the provision of service under this CPS, the CA will do what is neces-

sary to minimize disruption to the certificate holders and relying parties; in particular the CA shall:

at least 30 days before such termination, inform of its intentions all certificate holders and all entities

with which the CA has agreements in this regard;

with the same notice, publish a prominent notice on its website;

terminate all contracts with any subcontractor;

before the effective date of termination, transfer to another organization the obligation to keep the

registration information, certificate status information and all the relevant logs for the due time;

at the date of termination, destroy its private CA keys or render them unusable.

6 Technical security controls

The technological infrastructure, operating procedures, physical and logical security controls and personnel re-

sponsible for providing the service described in this CPS are the same as those used for the Actalis service for

issuing qualified certificates (according to the EU directive on electronic signatures).

6.1 Key generation

6.1.1 Root CA

Generation of the Root CA key pair takes place in a physically secured environment, according to the Root CA

internal procedures that require the joint intervention of two different people (“dual control”). Execution of

the key generation procedure (or “key ceremony”) is recorded by Actalis’ internal auditor.

The key pair used by the Root CA is generated inside a high quality HSM (Hardware Security Module) with secu-

rity certification in accordance with FIPS PUB 140-2 Level 3 and Common Criteria (ISO 15408) at EAL 4 or high-

er.



6.1.2 Sub CA

Generation of the Sub CA key pair takes place in a physically secured environment, according to the Sub CA in-

ternal procedures that require the joint intervention of two different people (“dual control”). Execution of the

key generation procedure (or “key ceremony”) is recorded by Actalis’ internal auditor.

The key pair used by the CA to sign the certificates and CRLs is generated inside a high quality HSM (Hardware

Security Module), with a security certification in accordance with FIPS PUB 140-2 Level 3 and Common Criteria

(ISO 15408) at EAL 4 or higher.

6.1.3 Subscribers

The applicant normally generates its own key pairs by his/her own means.

6.2 Distribution of public key

6.2.1 Root CA

As a minimum, the Root CA public key is distributed in the following ways:

by means of publication on the CA directory server (ldap://ldap.actalis.it)

by means of publication on the CA web site (www.actalis.it)

Depending on the agreements between Actalis and certain browser and/or operating system makers, the Root

CA public key may also be distributed in bundle with, or as an update of, such software products.

6.2.2 Sub CA

The Sub CA public key is provided to customers and in the form of an X.509 certificate signed by the Root CA,

together with the end user certificate.

Actalis may also distribuite the Sub CA public key by other means, if convenient.

6.2.3 Subscribers

The public key of the certificate requestor is supplied to the CA in the form of a Certificate Signing Request

(CSR) in compliance with PKCS#10 [RFC2314].

6.3 Key size

As for cryptographic algorithms, minimum length of keys, key parameters and hashing functions, the CA con-

forms to ETSI TS 102 176-1 and to Appendix A of [EVCG], with precedence of the latter in case of conflict be-

tween the two sets of requirements.

6.3.1 Root CA

The Root CA shall use a key with a module size of 4096 bit.

6.3.2 Sub CA

The Sub CA shall use a key with a module size of at least 2048 bit.

6.3.3 Subscribers

The module of subscriber keys shall have a size of 2048 bit.

ldap://ldap.actalis.it/




6.4 Parameters generation and key quality

6.4.1 Root CA

The Root CA uses a cryptographic key pair generated with the RSA algorithm, with a public exponent equal to

65537 (Hex 0x10001).

6.4.2 Sub CA

The Sub CA uses a cryptographic key pair generated with the RSA algorithm, with a public exponent equal to

65537 (Hex 0x10001).

6.4.3 Subscribers

Normally, the certificate subscriber uses a cryptographic key pair generated with the RSA algorithm.

The CA does not undertake to certify user keys generated with other algorithms (e.g. DSA, ECDSA).

6.5 Key usage (X.509v3 extension)

6.5.1 Root CA

The Sub CA certificate includes KeyUsage extension with the appropriate values which indicate the purpose of

the private key:

keyCertSign (sign certificates)

cRLSign (sign CRLs)

For further details see chapter 7.

6.5.2 Sub CA

The Sub CA certificate includes KeyUsage extension with the appropriate values which indicate the purpose of

the private key:

keyCertSign (sign certificates)

cRLSign (sign CRLs)

For further details see chapter 7.

6.5.3 Subscribers

See chapter 7.

6.6 Protection of private key

6.6.1 Root CA

The private key used by the Root CA is kept inside a high quality HSM (Hardware Security Module), with a secu-

rity certification in accordance with Common Criteria (ISO 15408) at EAL 4 or higher.



6.6.2 Sub CA

The private key used by the Sub CA is kept inside a high quality HSM (Hardware Security Module), with a securi-

ty certification in accordance with FIPS PUB 140-2 Level 3 or Common Criteria (ISO 15408) at EAL 4 or higher.

6.6.3 Subscribers

The CA does not mandate, but recommends, use of a hardware device (e.g. HSM) for protecting the subscrib-

er’s private key, provided that the solution adopted be reasonably effective in protecting its confidentiality. The

CA may refuse to issue the certificate if the system used by the requestor for protect its private is regarded as

inadequate by the CA.

6.7 Security Standard for cryptograph modules

The HSMs (Hardware Security Modules) used by the Root CA and the Sub CA shall possess a security certifica-

tion according to FIPS PUB 140-2 Level 3 and Common Criteria (ISO 15408) at EAL 4 or higher as detailed in pre-

vious sections.

6.8 Private Key (n out of m) Multi-Person Control

6.8.1 Root CA

The Root CA private key shall be under “N out of M” multi-person control. See also section 6.10.1.

6.8.2 Sub CA

No stipulation.

6.8.3 Subscribers

No stipulation.

6.9 Backup and recovery of private key

6.9.1 Root CA

For the purpose of guaranteeing continuity of service, the Root CA keeps an encrypted backup copy of its keys

on removable media. The backup copy is kept in a safe place which is different than the location of the opera-

tional copy (inside the HSM). Backup and restore procedures require the joint intervention of at least two peo-

ple (“dual control”).

6.9.2 Sub CA

For the purpose of guaranteeing continuity of service, the Sub CA keeps an encrypted backup copy of its keys

on removable media. The backup copy is kept in a safe place which is different than the location of the opera-

tional copy (inside the HSM). Backup and restore procedures require the joint intervention of at least two peo-

ple (“dual control”).

6.9.3 Subscribers

If technically feasible, the Subscriber is allowed to keep a backup copy of its private key for recovery purposes.

The confidentiality of the backup copy must be ensured by means not less effective than those used to protect

the operational copy.



6.10 Key activation data

6.10.1 Root CA

The Root CA key is normally kept in a non-operational state, except when needed for issuing or revoking Sub

CA certificates, by deactivating the HSM partition containing it.

Activation of the HSM partition requires the use of a dedicated PIN entry device (“PED”) connected directly to

the HSM and a set of USB-based two-factor authentication tokens each protected by a PIN. In particular, the

activation of the HSM partition containing the Root CA key requires inserting into the PED the Security Officer’s

token plus 3 other tokens out of 5 (“green tokens”), according to a secure secret sharing scheme. The 5 green

tokens are assigned to as many individuals within the company, in writing, who commit to keep them safely.

Therefore, the activation of the Root CA key requires the concurrent presence of at least 3 persons out of 5,

plus the Security Officer.

The Root CA Security Manager maintains a list of personnel that have been assigned the 5 green tokens. The

list will be made available for inspection during compliance audits.

6.10.2 Sub CA

The activation PIN (or other equivalent or better activation data) for the HSM used by the Sub CA is only known

by the personnel in charge of the CA operations on a “need to know” basis, under the responsibility of the CA

operations manager (or other suitable role).

6.10.3 Subscribers

The subscriber must ensure that the PIN or password needed to activate their private key is known to the cer-

tificate owner only, or to a delegated of them.

6.11 Computer security requirements and controls

The operating systems used by the CA for management of the certificates have been certified according to

Common Criteria at EAL2 or higher. The operating systems are configured so that the user is always required to

identify him/herself by means of a username and password or, in the case of more critical systems, via the use

of a smartcard and corresponding PIN. The access events are logged as described in section 5.4. The operating

systems are also subject to periodic hardening in order to disable non-necessary services and functionalities.

Certificate issuance and management is supported by a Certificate Management System (CMS) software. Web

interfaces (“WebRA/WebCA”), protected by TLS/SSL secure channel, are also implemented for performing rou-

tine certificate management operations by suitably authorized personnel. Multi-factor authentication is re-

quired for all CMS and WebRA/WebCA accounts capable of directly causing certificate issuance.

For performing most of the operations listed above the RA operator uses a specific type of account on the Cer-

tificate Management System. Such type of account requires strong two-factor authentication for logon. All se-

curity-relevant operations – e.g. authorization of certificate issuance – require the RA operator’s digital signa-

ture (smartcard-based) and are traced to the audit log.

6.12 Network security requirements and controls

Access to the CA on-line hosts is protected by high quality firewalls which guarantee an adequate filtering of

the incoming connections and also implement intrusion detection functionalities. Before the firewalls, a series



of routers which implement suitable ACLs (Access Control List) constitute further protection. All the communi-

cation ports of the certification servers which are not used are disabled. Only those ports are active which sup-

port the protocols and functions required for the operation and functionality of the service.

In order to strengthen the filter against communications the entire certification system is split-up into an ex-

ternal zone, internal zone and a De-Militarized Zone (DMZ). Sensitive systems are deployed on the internal

zone and cannot be directly accessed from the external zone.

Actalis carries out an annual security assessment to verify the presence of any network vulnerabilities by in-

volving independent experts.

6.13 Clock synchronisation

All the computer systems used by the CA are synchronised with a time server which in turn is synchronized

from an external GPS satellite network.



7 Certificate and CRL profiles

7.1 Certificate profile

The certificates conforms to the ISO/IEC 9594-8:2005 [X.509] standard and to the [RFC 5280] public specifica-

tion.

As for cryptographic algorithms, minimum length of keys, key parameters and hashing functions, the CA con-

forms to ETSI TS 102 176-1 and to Appendix A of [EVCG], with precedence of the latter in case of conflict be-

tween the two sets of requirements.

7.1.1 Root CA

The profile of the Root CA certificate is as follows:

Field Value

Version V3 (2)

SerialNumber (hex) 57:0A:11:97:42:C4:E3:CC

Signature sha256WithRSAEncryption (1.2.840.113549.1.1.11)

Issuer

CN = Actalis Authentication Root CA

O = Actalis S.p.A./03358520967

L = Milano

C = IT

Validity from September 22, 2011 to September 22, 2030

Subject


O = Actalis S.p.A./03358520967

L = Milano

C = IT

SubjectPublicKeyInfo <RSA public key of 4096 bits>

SignatureValue <Root CA signature>

Extension Value

Basic Constraints critical: CA=true

AuthorityKeyIdentifier (AKI) <included, KeyID>

SubjectKeyIdentifier (SKI) 52:D8:88:3A:C8:9F:78:66:ED:89:F3:7B:38:70:94:C9:02:02:36:D0

KeyUsage critical: keyCertSign, cRLSign

ExtendedKeyUsage (EKU) <not included>

CertificatePolicies <not included>

SubjectAlternativeName (SAN) <not included>

AuthorityInformationAccess (AIA) <not included>

CRLDistributionPoints (CDP) <not included>



7.1.2 Sub CA

The profile of the Sub CA certificate is as follows:

Field Value

Version V3 (2)

SerialNumber < includes at least 8 pseudo-random bytes>


Issuer


O = Actalis S.p.A./03358520967

L = Milano

C = IT

Validity <10 years>

Subject

CN = Actalis Authentication CA GN

O = Actalis S.p.A./03358520967

L = Milano

C = IT


SignatureValue <Root CA signature>

Extension Value

Basic Constraints critical: CA=true

AuthorityKeyIdentifier (AKI) <Same value as the Root CA SKI extension>

SubjectKeyIdentifier (SKI) <public key SHA1-digest>

KeyUsage critical: keyCertSign, cRLSign

ExtendedKeyUsage (EKU) <not included>

CertificatePolicies PolicyOID = 2.5.29.32.0 (anyPolicy) CPS-URI = <HTTP address of this CPS>

SubjectAlternativeName (SAN) <not included>

AuthorityInformationAccess (AIA) <HTTP address of OCSP responder>

CRLDistributionPoints (CDP) <HTTP address to access the ARL> <LDAP address to access the ARL>



7.1.3 SSL Server EV (Extended Validation)

The SSL Server EV certificate is issued with the following profile:

Field Value

Version V3 (2)

SerialNumber <8 random bytes>


Issuer <DN of issuing CA>

Validity <12 or 24 months depending on request>

Subject

C = <ISO 3166 two-letter code of country where the subscriber organization is based>

ST = <state or province where organization is based> L = <organization’s head office locality> O = <full legal name of subscriber organization> OU = <optional> CN = <one of the IP addresses or FQDNs contained in the SAN extension>

serialNumber = <VAT number of subscriber organization or

equivalent> businessCategory = <organization type, according to [EVCG]>

SubjectPublicKeyInfo <RSA public of 2048 bits>

SignatureValue <Sub CA signature>

Extension Value

Basic Constraints <absent>

AuthorityKeyIdentifier (AKI) <Same value as the Sub CA SKI extension>


KeyUsage critical: digitalSignature, keyEncipherment

ExtendedKeyUsage (EKU) serverAuth (1.3.6.1.5.5.7.3.1), clientAuth (1.3.6.1.5.5.7.3.2)

CertificatePolicies PolicyOID = 1.3.159.1.17.1 CPS-URI = <HTTP address of this CPS>

SubjectAlternativeName (SAN) <one or more IP addresses and/or hostnames>


CRLDistributionPoints (CDP) <HTTP address to access the CRL> <LDAP address to access the CRL>

The CA reserves the right to include in the certificate further information, in compliance with [RFC 5280], [BR]

and [EVCG], while ensuring the functionality of the certificate for its intended use.



7.1.4 Code Signing EV (Extended Validation)

The Code Signing EV certificate is issued with the following profile:

Field Value

Version V3 (2)




Validity <12, 24 or 36 months depending on request>

Subject

C = <ISO 3166 two-letter code of country where subscriber organization is based>

ST = <state or province where organization is based> L = <organization’s head office locality> O = <full legal name of subscriber organization> OU = <optional> CN = <value proposed by subscriber>

serialNumber = <VAT no. of subscriber organization or equivalent> businessCategory = <organization type, according to [EVCG]>

SubjectPublicKeyInfo < RSA public key of 2048 bits>


Extension Value




KeyUsage critical: digitalSignature

ExtendedKeyUsage (EKU) critical: codeSigning (1.3.6.1.5.5.7.3.3)


SubjectAlternativeName (SAN) <optional>



The CA reserves the right to include in the certificate further information, in compliance with [RFC 5280], [BR]

and [EVCG], while ensuring the functionality of the certificate for its intended use.



7.1.5 SSL Server OV (Organization Validated)

The SSL Server OV certificate is issued with the following profile:

Field Value

Version V3 (2)




Validity <12 or 24 or 36 months depending on request>

Subject

C = <ISO 3166 two-letter code of country where the subscriber organization is based>

ST = <state or province where organization is based> L = <organization’s head office locality> O = <full legal name of subscriber organization> OU = <optional> CN = <one of the IP addresses or FQDNs contained in the SAN extension>



Extension Value










The CA reserves the right to include in the certificate further information, in compliance with [RFC 5280] and

[BR], while ensuring the functionality of the certificate for its intended use.



7.1.6 SSL Server Wildcard OV (Organization Validated)

The Wildcard SSL Server OV certificate is issued with the following profile:

Field Value

Version V3 (2)





Subject

CN = <ISO 3166 two-letter code of country where subscriber organization is based>

ST = <state or province where organization is based> L = <organization’s head office locality> O = <full legal name of subscriber organization> OU = <optional> CN = <Wildcard FQDN, also contained in the SAN extension>



Extension Value

Basic Constraints <if included, is critical and contains CA=FALSE>






SubjectAlternativeName (SAN) <Same wildcard FQDN as in the Subject.CN field>







7.1.7 Code Signing OV (Organization Validated)

The Code Signing OV certificate is issued with the following profile:

Field Value

Version V3 (2)





Subject

C = <ISO 3166 two-letter code of country where subscriber organization is based>

ST = <state or province where organization is based> L = <organization’s head office locality> O = <full legal name of subscriber organization> OU = <optional> CN = <value proposed by subscriber>

SubjectPublicKeyInfo < RSA public key of 2048 bits>


Extension Value




KeyUsage critical: digitalSignature

ExtendedKeyUsage (EKU) critical: codeSigning (1.3.6.1.5.5.7.3.3)


SubjectAlternativeName (SAN) <optional>







7.1.8 SSL Server DV (Domain Validated)

The SSL Server DV certificate is issued with the following profile:

Field Value

Version V3 (2)




Validity <12 or 24 or 36 months depending on request>

Subject OU = “Domain Control Validated by Actalis S.p.A.” CN = <one of the IP addresses or FQDNs contained in the SAN extension>



Extension Value














7.1.9 SSL Server Wildcard DV (Domain Validated)

The Wildcard SSL Server OV certificate is issued with the following profile:

Field Value

Version V3 (2)





Subject OU = “Domain Control Validated by Actalis S.p.A.” CN = <Wildcard FQDN, also contained in the SAN extension>



Extension Value

Basic Constraints <if included, is critical and contains CA=FALSE>






SubjectAlternativeName (SAN) <Same wildcard FQDN as in the Subject.CN field>







7.2 CRL profile

The CRLs are compliant with the with the ISO/IEC 9594-8:2005 [X.509] International Standard and public speci-

fication [RFC 5280].

Besides the mandatory information, the CRLs also contain:

nextUpdate (date for next issue of CRL)

cRLNumber (sequential number of CRL)

The CRL is signed using the hashing algorithm sha256WithRSAEncryption (1.2.840.113549.1.1.11).

Moreover, in correspondence with each item of the CRL there is a reasonCode extension to indicate the rea-

sons for suspension or revocation.

8 Compliance audits and other assessments

The technological infrastructure, physical and logical security controls, several operating procedures, and the

personnel employed in providing the CA service described in this CPS are the same as those used for issuing

qualified certificates according to the EU directive on electronic signatures.

Actalis is a Qualified Certification Service Provider (CSP) according to European legislation; as such, it is subject

to a periodic conformity assessment (“supervision”) by AgID1 and is required to perform periodic internal

audits.

8.1 Frequency or circumstances of assessment

The external audits performed by AgID are carried out with the periodicity (18 months) required by the CNIPA

Circular n.52 of 2007. Regardless of that, Actalis commits to do what is necessary so that a compliance audit be

done at least every 12 months, if necessary by engaging an external independent auditing firm so to enforce

the annual periodicity.

The internal audits are carried out in accordance with a schedule which provides different periods (from quar-

terly to annual) for the various technical-operational aspects of the CA service.

8.1.1 Root CA

A compliance audit on the Root CA is performed at least annually by an external, independent and suitably

qualified auditor on the basis of auditing criteria ETSI TS 102 042 [REQPOL].

8.1.2 Sub CA

A compliance audit on the Sub CA is performed at least annually by an external, independent and suitably qual-

ified auditor on the basis of auditing criteria ETSI TS 102 042 [REQPOL].

8.1.3 Registration Authorities

Inspections on Registration Authorities (if any exist) are performed at least annually by the Sub CA.

1 Agenzia per l’Italia Digitale: see www.digitpa.gov.it

http://www.digitpa.gov.it/



8.2 Identity and qualification of assessor

The internal audits are carried out by Actalis’ internal auditor, who is suitably qualified for the task.

External audits, are performed by independent and suitably qualified auditors.

8.3 Assessor’s relationship to assessed entity

No relationship shall exist between the CA and any external auditors that can influence the outcome of the au-

dits in favor of Actalis.

Actalis’ internal auditor does not belong to the organizational unit in charge of CA operations.

8.4 Topics covered by assessment

Audits performed by external assessors (other than AgID) are aimed at verifying compliance of Actalis’ CA ser-

vice to this CPS based on ETSI TS 102 042 auditing criteria [REQPOL].

The main objective of the internal audit is to verify the respect of Actalis’ internal operating procedures and

their compliance with this CPS.

8.5 Actions taken as a result of deficiency

In the case of non-compliances, AgID will require the CA to adopt the necessary corrective measures within a

certain period of time, under penalty of suspension or revocation of the accreditation.

Non-compliances found by other external auditors are brought to the attention of Actalis’ top management

who decides how to handle them on a case-by-case basis.

8.6 Communication of results

The results of the audit carried out by AgID are communicated to the CA by a special audit report.

The results of internal audits are presented directly to Actalis' top management, and shared with the other in-

ternal stakeholders, via an audit report.



9 Other business and legal matters

The general Terms & Conditions of the CA service herein described are provided to customers as a separate

document, to be accepted at application time, published on the CA web site (see §2.2).

In the case of a discrepancy between this CPS and the separate “Terms & Conditions” document, this CPS will

take precedence.

9.1 Service fees

The maximum service fees are published on the CA web site: www.actalis.it.

Different conditions may be negotiated case by case, in accordance with the volumes requested.

Service fees are subjected to change without prior notification.

9.2 Financial responsibility

Actalis maintains the following insurance related to its performance and obligations under this CPS:

A. Commercial General Liability insurance with policy limits of at least two million US dollars in coverage;

and

B. Professional Liability/Errors and Omissions insurance, with policy limits of at least five million US dol-

lars in coverage, and including coverage for (i) claims for damages arising out of an act, error, or omis-

sion, unintentional breach of contract, or neglect in issuing or maintaining EV and non-EV Certificates,

and (ii) claims for damages arising out of infringement of the proprietary rights of any third party (ex-

cluding copyright, and trademark infringement), and invasion of privacy and advertising injury.

Such insurance is with a company rated no less than A- as to Policy Holder’s Rating in the current edition of

Best’s Insurance Guide.

9.3 Privacy of personal information

Actalis is the processor of the personal information collected during the identification and registration phase of

parties requesting certificates under this CPS, and shall process such information ensuring their confidentiality

and in compliance with the Italian Legislative Decree n.196/2003 [DLGS196].

9.3.1 Information pursuant to Legislative Decree n.196/2003

Actalis, processor of the personal data provided by the subscriber, hereby informs the subscriber that, pursuant

to the Italian Legislative Decree 196/2003 [DLGS196], such personal data shall be processed by means of both

paper archives and information systems that guarantee their security and confidentiality in keeping with the

aforesaid Decree.

The information supplied by the applicant falls into two categories: mandatory and optional. The mandatory

information is necessary for delivering the requested service; failure by the subscriber to provide that infor-

mation will not allow the contract to be concluded. The optional information is used to assist in the service;

failure by the subscriber to provide this information will not prevent the contract to be concluded.

The information provided by the applicant is processed exclusively for the purpose of issuing and managing the

certificates, and can be communicated to companies providing consultancy and technical support to the CA. In




relation to this data processing, the applicant shall be granted the rights provided for in aforesaid Decree

[DLGS196].

9.3.2 Archives containing personal information

The archives containing personal data are:

CA database (comprised of multiple logically distinct databases)

paper archives (kept in secure storage with access restrictions)

The aforementioned archives are managed by the CA operations manager and are suitably protected against

unauthorized access.

9.3.3 Privacy protection measures

Actalis complies with the provisions of the Italian Legislative Decree n.196/2003 [DLGS196], and subsequent

modifications and amendments, by putting in place suitable security controls which, at least, conforms to

Chapter II (“Minimum security measures”) of the aforesaid Decree. In particular, Actalis:

adopts suitable measures to control access to the archives

adopts suitable procedures for management of authentication credentials

keeps a permanent audit log of access to the archives

performs periodic backup of data for recovery purposes.

Within the service regulated by this CPS, the CA does not collect and does not process sensitive data nor judi-

cial data (with reference to article 4 of the aforesaid Decree [DLGS196]).

9.4 Intellectual property rights

This CPS is the property of Actalis who reserves all rights associated with the same.

The subscriber of the certificate keeps all the rights on its own commercial marks (brand names) and its own

domain names.

With regards to the property rights of other data and information, the applicable law shall be applied.

9.5 Obligations and guarantees

9.5.1 Certification Authority

The CA shall:

operate in compliance with this CPS;

identify the applicants as described in this CPS;

issue and manage the certificates as described in this CPS;

provide an efficient suspension and revocation service for the certificates;

guarantee that the subscriber, at the time when the certificate is issued, did possess the corresponding

private key;

timely inform about any eventual compromise of its own private key;



provide clear information about the procedures and requirements of the service;

provide a copy of this CPS to anyone requesting it;

guarantee processing of personal data in compliance with applicable law;

provide an efficient and reliable information service about the status of the certificates.

9.5.2 Registration Authority

This section only applies to external RAs, that is, to Customers acting as Enterprise RAs (see §1.3.2). They have

the following obligations:

only use the procedures and tools provided by the CA, and only in the way provided by the CA;

access the web-based certificate management interface provided by the CA only from clean working

stations (e.g. PCs), equipped with a good quality- and regularly updated antivirus;

ensure confidentiality of the credentials provided by the CA to access the web-based certificate

management interface.

9.5.3 Subscribers

Certificate Subscribers, namely certificate owners, shall:

read, understand and fully accept this CPS;

request the certificate by the methods prescribed in this CPS;

provide the CA with precise and true information during the registration phase;

ensure confidentiality of secret codes (e.g. passwords) provided to them by the CA;

adopt suitable technical and organizational measures to avoid compromise of their own private keys;

install and start using the certificate only after having checked that it contains correct information;

use the certificate only in the ways and for the purposes provided for in this CPS;

never use their private keys, for no reason whatsoever, for issuing other certificates in turn;

in the event of confirmed compromise of any of their own private keys, immediately request

revocation of the corresponding certificates and immediately stop using those certificates;

in the event of CA compromise, immediately stop using their certificates;

immediately request revocation of the certificate in the case when any of the information contained in

the certificate (i.e. company name, web site address etc.) is no longer valid;

immediately inform the CA, after issue and up to expiry or revocation of the certificate, of any changes

in the information supplied during the application phase;

respond within 48 ore to requests by the CA related to possible improper use of certificates or possible

key compromises;

upon revocation of their certificate(s), immediately stop using the revoked certificates, and:

– in the case of Code Signing certificates: immediately remove the signed software from the web

sites on which it is published;

– in the case of SSL Server certificates: immediately remove the certificate from the web site on

which it is installed.

stop using certificates upon their expiration.



Moreover, the subscribers of certificates shall:

in the case of Code Signing certificates: not sign malicious software (malware) and not describe the

signed software in a misleading way with respect to its real functionality and purpose;

in the case of SSL Server certificates: exclusively install the certificate on the proper web sites and

domains (as indicated in the certificate) and operate those web sites only in ways allowed by this CPS

and for lawful purposes only.

Subscribers acknowledge and accept that the CA, if made aware that a Subscriber’s certificate is being used for

unlawful purposes (e.g. phishing, Man-In-The-Middle attacks, distribution of malware, etc.), or for issuing other

certificates, will immediately revoke that certificate without notice.

9.5.4 Relying parties

The term “Relying Parties” refers to all those entities (other than subscribers) that rely on certificates for taking

a decision (such as: making information or resources available to the certificate owner, use/process the re-

sources or information obtained from the certificate owner, etc.).

The relying parties, when dealing with certificates issued under this CPS, are required to:

make a reasonable effort to acquire a sufficient understanding of certificates and PKIs;

verify the status of certificates by accessing the information services described at §4.10;

only rely on certificates which are not expired, nor suspended nor revoked.

9.6 Disclaimers of warranties

The CA has no further obligations and shall not be obliged to guarantee anything more than what is described

in this CPS (refer to section 9.5.1) or prescribed by applicable law.

9.7 Limitations of liability

The CA declines any responsibility for damages suffered by anyone due to the non-fulfilment, by the client or

third parties, of one or more parts of this CPS.

The CA declines any responsibility for damages suffered by the client due to non-reception of communications

from the CA as a consequence of an incorrect e-mail address supplied during the application phase.

Without prejudice to the mandatory provisions of law, Actalis shall only be held responsible, for any reason

whatsoever deriving from this CPS, in the cases of malice or gross negligence.

9.8 Indemnities

Customers shall pay compensation of any damages suffered by Actalis in the following cases:

false declarations in the certification request;

failure to provide information to the CA about essential matters and facts due to negligence or with

the objective of deceiving the CA;

use of names (for example, domain names, brand names) in violation of intellectual property rights;

use of certificates for unlawful purposes and/or for purposes not allowed by this CPS.



9.9 Term and termination

This CPS shall enter into force at the time it is published on the CA web site (see chapter 2) and shall remain in

force until it is replaced with a new version.

9.10 Correspondence

Actalis accepts correspondence related to this CPS, to be sent with the methods indicated at §1.5, and shall re-

spond within five working days.

Problems and complaints related to certificates issued under this CPS (e.g. possible misuses, problems access-

ing certificate status information, possible breach of this CPS, etc.) can be reported to the CA at any time by

sending e-mail to [email protected]. Or, send a letter to the following address:

Assistenza Clienti

ACTALIS S.p.A.

Via dell’Aprica 18

20158 Milano

ITALIA

The message or letter must include, in addition to a clear description of the alleged problem, at least the name

and telephone number of the sender. Actalis commits to examine all proper messages within 2 working days

and take the necessary steps.

9.11 Amendments

Actalis reserves the right to modify this CPS at any time whatsoever without prior notification.

9.12 Resolution of disputes

Any controversies deriving from this CPS between Actalis and the clients of the service shall be deferred to an

arbitration committee. The seat of the arbitration shall be in Milan, Italy.

9.13 Applicable law

This CPS is subject to Italian Law and as such shall be interpreted and carried out. For that not expressly pre-

scribed in this CPS, the applicable law shall prevail.

Other contracts in which this CPS is incorporated by means of reference, may contain distinct and separate

clauses with respect to applicable law.

9.14 Compliance with applicable law

At the revision date of this CPS, Actalis is not aware of any legislation relevant to the services described herein.

In any case this CPS shall be subject to applicable laws.

9.15 Force majeure

Actalis shall not be responsible for the failure to carry out the obligations assumed herein in the case when

such non-fulfilment is due to causes not attributable to Actalis, such as – for instance, but not limited to – act of

providence, unforeseen technical problems completely out of any form of control, intervention by the authori-

ty, force majeure, natural disasters, industrial actions including company strikes – inclusive of those at the




premises of parties which are used for the execution of the activities associated with the services described

herein, and other causes attributable to third parties.

9.16 Service levels

The CA guarantees the following minimum service levels:

Metric Objective Measurement basis

Directory server availability (24 x 7) 99.8 % annual

Web portal availability (24 x 7) 99.8 % annual

Certificate issuing time max 5 working days in 95% of all cases

annual

Time for certificate suspension or revocation (when requested through the CA web site)

max 2 minutes in 95% of all cases

annual

Time for certificate revocation (when requested by e-mail, ordinary mail or fax)

max 6 hours in 95% of all cases

annual

certification practice statement · certification practice statement ssl server and code signing...

Documents