Experian Information Securitypks.experian.com/experian_certificate_policy_20090624.pdf · Experian...

Experian - Public 1

Experian Information Security

Certificate Policy Statement Overview

The following Certificate Policy and Certification Practice Statement serve as requirements for establishing trust with Experian’s S/MIME encrypted e-mail solution. Reliance upon this policy shall rest on the requirements established herein and the enforcement of these requirements. Certificates issued under this policy shall be referred to as Experian Certificates or Certificates.

Certificate Policy This Certificate Policy (CP) is designed to communicate with internal business partners about the security environment surrounding Experian’s implementation of S/MIME encrypted e-mail solution. By formalizing the practices around this service these business partners, known as relying parties, may follow open standards for establishing protected communications with Experian. The official standard for Certificate Policies (RFC 3647) defines a Certificate Policy as follows:

Certificate policy (CP) - A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular CP might indicate applicability of a type of certificate to the authentication of parties engaging in business-to-business transactions for the trading of goods or services within a given price range.

The following document serves as the Certificate Policy, with regard to digital certificates generated by Experian.

Experian - Public 2

Document Control

Name Description of Changes Date Version John Eder Release initial version 5-31-05 0.01 Bill Spernow Review and revisions 8-10-05 0.05 Terry Sexsmith External consultant review 9-1-05 0.07 Mark Lundin External audit review 9-17-05 0.09 External Lawyer External legal review 9-28-05 1.00 Michael Scheu Review and revisions 2-28-06 1.10 Michael Scheu Allowances for Group Mailboxes 8-15-06 1.11 Michael Scheu Review and revisions 7-22-08 1.12 Daniel King Review and revisions 6-24-09 1.13

Experian - Public 3

TABLE OF CONTENTS TABLE OF CONTENTS.......................................................................................................................................................................3 1 INTRODUCTION ..............................................................................................................................................................................5

1.1 Overview ....................................................................................................................................................................................5 1.2 Identification ..............................................................................................................................................................................6 1.3 Community and Applicability ...................................................................................................................................................6 1.4 Certificate Usage ......................................................................................................................................................................9 1.5 Policy Administration ..............................................................................................................................................................10 1.6 Definitions and Acronyms......................................................................................................................................................11

2 PUBLICATION AND REPOSITORY RESPONSIBILITIES.........................................................................................................15 2.1 Publication and Repositories .......................................................................................................................................15

3 IDENTIFICATION AND AUTHENTICATION.............................................................................................................................16 3.1 Naming .....................................................................................................................................................................................16 3.2 Initial Identity Validation .........................................................................................................................................................16 3.3 Identification and Authentication for Re-Key Requests ....................................................................................................18 3.4 Identification and Authentication for Suspension and Revocation Requests ................................................................18 3.5 Identification and Authentication for Recovery Requests .................................................................................................19

4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS.............................................................................................20 4.1 Certificate Application ............................................................................................................................................................20 4.2 Certificate Application Processing........................................................................................................................................20 4.3 Certificate Issuance................................................................................................................................................................20 4.4 Certificate Acceptance ...........................................................................................................................................................21 4.5 Key Pair and Certificate Usage ............................................................................................................................................21 4.6 Certificate Renewal ................................................................................................................................................................21 4.7 Certificate Re-Key ..................................................................................................................................................................22 4.8 Certificate Modification...........................................................................................................................................................22 4.9 Certificate Suspension and Revocation ..............................................................................................................................22 4.10 Certificate Status Services ..................................................................................................................................................24 4.11 End of Subscription ..............................................................................................................................................................24 4.12 Key Escrow and Recovery ..................................................................................................................................................24 4.13 Customer Service .................................................................................................................................................................25

5 MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS...........................................................................................26 5.1 Physical Security Controls.....................................................................................................................................................26 5.2 Procedural Controls................................................................................................................................................................27 5.3 Personnel Controls .................................................................................................................................................................28 5.4 Audit Logging Procedures .....................................................................................................................................................29 5.5 Records Archival.....................................................................................................................................................................31 5.6 Key Changeover .....................................................................................................................................................................31 5.8 CA Termination/Change in Operations ...............................................................................................................................33 5.9 Customer Service ...................................................................................................................................................................33

6. TECHNICAL SECURITY CONTROLS ........................................................................................................................................34 6.1 Key Pair Generation and Installation ...................................................................................................................................34 6.2 Private Key Protection and Cryptographic Module Engineering Controls......................................................................35 6.3 Other Aspects of Key Pair Management.............................................................................................................................37 6.4 Activation Data ........................................................................................................................................................................38 6.5 Computer Security Controls ..................................................................................................................................................39 6.6 Life Cycle Technical Controls ...............................................................................................................................................39 6.7 Network Security Controls.....................................................................................................................................................40 6.8 Time-stamping ........................................................................................................................................................................40

7 CERTIFICATE AND CRL PROFILE..............................................................................................................................................41 7.1 Certificate Profile ....................................................................................................................................................................41 7.2 CRL Profile ..............................................................................................................................................................................42 7.3 OCSP Profile ...........................................................................................................................................................................43

8 COMPLIANCE INSPECTION AND OTHER ASSESSMENTS....................................................................................................44 8.1 Frequency or Circumstances of Assessment .....................................................................................................................44 8.2 Identity and Qualifications of Assessor ...............................................................................................................................44 8.3 Assessor's Relationship to Assessed Entity .......................................................................................................................44 8.4 Topics covered by Assessment............................................................................................................................................44

Experian - Public 4

8.5 Actions Taken as a Result of Deficiency.............................................................................................................................44 8.6 Communication of Assessment Results .....................................................................................................................................45

9 OTHER BUSINESS MATTERS......................................................................................................................................................46 9.1 Fees ..........................................................................................................................................................................................46 9.5 Intellectual Property Rights ...................................................................................................................................................47 9.6 Participant Obligations ...........................................................................................................................................................47 9.7 Disclaimers of Warranties .....................................................................................................................................................51 9.16.1 Cross-certification and Recognition................................................................................................................................52 9.16.2 Cross-certification .............................................................................................................................................................52 9.16.3 Recognition of Other CAs ................................................................................................................................................52

Experian TSB – Certificate Policy

Experian – Public 5

1 INTRODUCTION

1.1 Overview Based on the recommendations of the Internet Engineering Task Force for Public Key Infrastructure (RFC 3647) and the Experian Risk Management Committee, this Certificate Policy establishes the Certificate Policy (or CP) for deploying Certificates to protect the integrity and confidentiality of information shared within Experian North America, Inc., its affiliates and subsidiaries (collectively, Experian). Experian adopts this corporate policy to govern the use of encryption Keys and Certificates for secure communications and desktop encryption. Secure communication serves as a cornerstone to good business relationships. This Certificate Policy applies to all Certificates issued within Experian, including those issued by the Experian Primary Certificate Authority (CA) and Experian’s subordinate CAs. The Certificates issued under this Certificate Policy shall be subject to the requirements established in this Certificate Policy. Cross-certification between Experian and non-Experian Certificate Authorities shall be allowed based on the requirements described in this Certificate Policy. A formal risk analysis shall be initiated prior to cross certification to ensure that a comparable level of security and identity are established in both environments. The digital signature provisions address the management and use of Certificates containing Public Keys used for authentication and data integrity. The confidentiality provisions apply to the management and use of Certificates containing Public Keys used to establish encryption Keys and Key transfers. The confidentiality Certificates issued under these policies are suitable for protecting information, as described in this Certificate Policy. This Certificate Policy is subject to the laws governing the appropriate jurisdiction(s). Business Information Security Officers may require additional information, proof of identity or authorization for establishing identity. Parties relying on this Certificate Policy shall preserve the integrity, confidentiality and availability of information owned and exchanged Experian. This Certificate Policy, the issuance of a Certificate, or any additional requirements implemented by Experian in accordance with this Certificate Policy does not, in any way, entitle the Subscriber to any right or benefits under any Experian contract. Experian may, at its sole discretion, refuse to issue a Public Key Certificate or revoke an existing Certificate at any time. EXPERIAN DISCLAIMS ANY AND ALL REPRESENTATIONS AND WARRANTIES OF ANY TYPE WITH RESPECT TO ANY CERTIFICATE ON WHICH A PARTY MAY RELY, WHETHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, RELIABILITY, AND INFRINGEMENT. ACCEPTANCE, RELIANCE AND USE OF ANY CERTIFICATE SHALL BE AT THE PARTY’S OWN RISK, AND UNDER NO CIRCUMSTANCES SHALL EXPERIAN OR ANY CA BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, SPECIAL OR INCIDENTAL DAMAGES ARISING FROM THE ISSUANCE OR USE OF CERTIFICATES OR PROVISION OF PKS, WHETHER IN CONTRACT OR IN TORT, EVEN IF EXPERIAN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Any use of the term “assurance” in this Certificate Policy shall not be construed to be a representation or warranty. Any representations, warranties, or liability for damages shall be specifically documented in separate written agreements and shall be appropriately titled as such. All references to data classification are based on Experian’s Information Security Policy. The policy establishes the following definitions for data classification:

• Experian Public – Information that has been explicitly approved by Experian management for release to the public.

• Experian Internal (default) – All Experian non-public information that cannot be clearly classified as Confidential or Restricted.



• Experian Confidential– Sensitive business information which is generally for use within Experian, where the potential consequences of unauthorized disclosure or misuse outweigh the benefits of widespread dissemination to all Experian staff.

• Experian Restricted– The most highly sensitive or critical information that is restricted among Experian employees, Experian legal entities or Business Units specified by the Information Steward that would affect the competitive position or have a substantial detrimental impact if it were released.

This Certificate policy shall support two classifications of Certificates for enhancing security. This classification is founded in the policy titled (i) Experian Confidential Certificates and (ii) Experian Restricted Certificates. The Certificates issued under this Certificate Policy are intended for the following two types of services:

Experian Confidential Certificates: o Protection of “Experian Confidential” and “Experian Internal” data.

Experian Restricted Certificates:

o Protection of any classification of data under the Experian policy up to and including “Experian Restricted.”

o Protection of automated product transactions containing credit data. Examples of the services Certificates support within this framework:

Experian Confidential Certificates – Electronic-Mail containing confidential data, file cabinet Key-and-lock database, Experian Trade Line data, Passwords, sub-code and password, employee personal information, personnel information Experian Restricted Certificates – Electronic-Mail containing restricted data, Private Key encryption source code, negotiable instruments, investigative or incident reports.

Business managers, supported by their Chief Information Security Officers, hold responsibility for the selection of the appropriate Certificate for their application, and whether they shall issue both digital signature and confidentiality Key pairs and Certificates, or only one or the other. The use of dual authorization (i.e. where two administrators must approve a change) shall protect sensitive activities. Single, trusted personnel may perform other non-sensitive functions. The Certification Practice Statement (CPS or Technical Security Baselines) document shall specify the exact activities requiring dual Key authorization. This infrastructure shall be owned and managed by Experian. Public Key technology exists to facilitate and extend Experian’s business. All efforts to leverage this technology shall remain focused on Experian’s vision for strategic operations and delivering service to our customers. Keeping with this service focus, this Certificate Policy shall refer to the policy, process, and environment as Public Key Services (PKS). This is exactly equivalent to Public Key Infrastructure, and serves to enunciate Experian’s focus on continuously improving information security and services for our customers.

1.2 Identification Certificate Policy Experian Public Key Services 1.3.6.1.4.1.3101.7 The Public Key Services OID hierarchy is defined in section 7.1.6.

1.3 Community and Applicability Experian shall manage all components of the Public Key Services (PKS), including the Primary Certificate environment, the Subject Certificate environment, and the subscribers. All policy administration occurs through the Experian Information Security Office.



1.3.1 Issuing Certificate Authority (CA) Experian’s Certificate Authorities (CA) shall act within the bounds of this Certificate Policy while issuing and supporting the Certificate environment. This environment of trust serves as the framework for supporting Public Key Services encryption at Experian. The Certification Practice Statements (CPS) shall cover the implementation in more specific details. Certificate classification flows from the underlying function the encryption supports and the data classification (Proprietary, Confidential, or Restricted). Experian is responsible for this Certificate Policy. Within Experian, a Business Information Security Officer shall be tasked with the operation of one or more Certificate Authority servers. These servers issue and manage Public Key Certificates and Certificate Revocation Lists issued in accordance with this Certificate Policy. Compliance with this Certificate Policy serves to protect relying parties and extend the trustworthiness of Experian’s business. Accordingly, the term “CA” in this Certificate Policy means the service owners tasked with the provisioning of CA services for their Business Unit, with the approval of the Information Security Office. The CA is accountable to the Risk Management Committee for the:

o Application of this Certificate Policy; o Development of Certification Practice Statement (CPS) in accordance with this Certificate Policy to document the

CA’s compliance with this Certificate Policy and other requirements; o Maintenance of the Certification Practice Statement (CPS) to ensure that it is updated as required; and o Supervision of BISO performing CA functions in accordance with the CPS.

Operational roles:

o The Business-unit Information Security Officer is responsible for (i) the configuration and maintenance of systems for the CA infrastructure; (ii) commencement and cessation of CA services; and (iii) the initial creation of accounts for Public Key Service (PKS) officers.

o A Public Key Service (PKS) officer is responsible for the management of PKS Administrators as well as other PKS Officers and the configuration of CA security policies.

o Public Key Service (PKS) Administrator is responsible for (i) the management of the Subscriber initialization process; (ii) the creation, renewal or revocation of Certificates and (iii) the distribution of tokens (where applicable).

An organizationally separate assessor shall perform all compliance audits. The Experian Help Desk shall assist Subscribers with Certificate issuance, maintenance or revocation. Automation to facilitate these activities is allowed where possible to meet these requirements, and where the users have access to the Experian PKS infrastructure. 1.3.2 Designated Certificate Holders Under certain circumstances, automation may require a device to hold a Certificate. In these situations, an individual user shall take ownership responsibility for these Certificates and the associated security. An individual designated by a Business Unit to be the holder of a Certificate issued to a role, device or application for use on behalf of a Business Unit, may be a Designated Certificate Holder. This Certificate Policy conveys the trust framework designed to protect communications to Experian and reliance on the security built into the Certificate environment. The CA may refuse to issue Certificates in accordance with the Certification Practice Statement (CPS). 1.3.3 Registration Authorities (RA) The RA shall verify a Designated Certificate Holder’s authority to act on behalf of a Business Unit. While the RA initiates the process to cause the CA to issue Certificates, it does not sign or issue Certificates. The RA may leverage on-line automation where possible to meet these requirements.



The registration authority shall only perform the functionality delegated by the Certificate Authority. 1.3.4 Subscribers The CA may issue Certificates to Experian employees and Experian Business Units that comply with all requirements of this Certificate Policy and that have established their identity as required under this Certificate Policy. Throughout this Certificate Policy a “Subscriber” means any responsible individual who has been issued a Certificate (i) as the named subject, (ii) on behalf of the organization for cross-certification, (iii) on behalf of a device for automation purposes, (iv) on behalf of a non-entity for group mailboxes. For the purposes of extending trust to other Experian Certificate Authorities and client Certificate Authorities, Certificates may be issued by the CA. These Certificates shall be titled “cross-Certificates.” This Certificate Policy conveys the trust framework designed to create trust in secure communications within Experian and with client Certificate Authorities using Experian PKS. The CA may refuse to issue Certificates in accordance with the Certification Practice Statement (CPS). 1.3.5 Relying Parties Anyone who uses the infrastructure described within this Certificate Policy to protect Experian information or communications is considered a relying party. This group of individuals relies on the infrastructure to properly implement enterprise encryption. With respect to Certificates issued under this Certificate Policy, a relying party is either:

o A subscriber of an Experian CA; or o Experian device or application.

Individuals or organizations, other than those listed above, shall rely upon Certificates issued by the Experian CA at their own risk. 1.3.6 Applicability and Applications Experian Certificates support enhanced confidentiality and integrity of information transmitted through electronic means. This communication may travel internally within Experian or in exchange with Experian clients. The Certificates governed by this Certificate Policy shall only be issued to authorized users with Experian network privileges. Issuing of Certificates to external users for anything other than extending trust to a third party CA is not supported by this Certificate Policy. The Experian PKS trust environment enhances confidentiality and integrity through PKS encryption and digital signatures. This enhancement may serve any Experian application requiring the use of secure PKS technology. 1.3.7 Other Participants Experian Risk Management Committee Experian Risk Management Committee is an inter-departmental committee consisting of senior executives within Experian that hold responsibility for:

o Approving Experian CA Certificate Policies o Approving Experian CA Certification Practice Statements o Providing policy direction to the Experian CA; and o Recommending any cross-certification or interoperability agreements with external CA environments.

The Chief Information Security Office is responsible to the Risk Management Committee for Experian.



The Global Security Steering Committee shall assist the Chief Information Security Office with review and recommendations on changes to this Certificate Policy. Accreditation Authority The Chief Information Security Office for Experian is responsible for accrediting that Experian CAs meet the appropriate requirements, established within this Certificate Policy. Repository Manager The Repository Manager under the supervision of the Business Information Security Office is responsible for maintaining and protecting one or more:

o Repositories holding relevant information such as public Certificates and Certification Revocation Lists (CRL); or o On-line Certificate status checking servers.

Each CA shall have at least one Certificate and CRL repository associated with it. The CA may perform the repository function on the same infrastructure as the CA functions. The CA shall establish terms and conditions of its association with the Repository Manager, including, without limitation, availability, access control, integrity of data, protection of personal information, directory replication, directory chaining, and if applicable, directory referrals. Business-Unit Information Security Officer (BISO) A Business-Unit Information Security Officer (BISO) is an individual with the Business Unit responsible for the management of a particular Experian CA. The BISO in conjunction with the Chief Information Security Office (CISO) may impose further requirements over and above those employed by the CA for registration purposes. The CISO, supported by the Business Information Security Office, shall use policies including whether their internal users shall be issued either or both digital signature and confidentiality Key pairs and Certificates, or only one or the other.

1.4 Certificate Usage This Certificate Policy is subject to applicable law, and the provision of PKS shall be in accordance with applicable laws governing the appropriate jurisdiction(s). 1.4.1 Data Classification All references to data classification are based on Experian’s Information Security Policy. The policy establishes the following definitions for data classification:

• Experian Public – Information that has been explicitly approved by Experian management for release to the public.

• Experian Internal (default) – All Experian non-public information that cannot be clearly classified as Confidential or Restricted.



1.4.2 Certification Classification



This Certificate policy shall support two classifications of Certificates for enhancing security. This classification is founded in the policy titled Experian Confidential Certificates, and Experian Restricted Certificates. The Certificates issued under this Certificate Policy are intended for the following two types of services:

Experian Confidential Certificates: o Protection of “Experian Confidential,” and “Experian Internal” data.


o Protection of any classification of data under the Experian policy up to and including “Experian Restricted.”

o Protection of automated product transactions containing credit data. These Certificates are generally established on servers for integrated processes, without human intervention.

Additional requirements for restricted Certificates are found in Sections 3.2.3, 4.5.3, 4.9.3, 5.1.2, 6.2.1 and 7.2

1.4.3 Data Examples Examples of the services Certificates support within this framework:

Experian Confidential Certificates – Electronic-Mail containing confidential data, file cabinet Key-and-lock database, Experian Trade Line data, passwords, sub-code and password, employee personal information, personnel information Experian Restricted Certificates – Electronic-Mail containing restricted data, Private Key encryption source code, negotiable instruments, investigative or incident reports.

1.4.4 Certificate Selection Business managers, supported by their Business Information Security Officers, maintain responsibility for the selection of the appropriate Certificate for their application, and whether they shall issue both digital signature and confidentiality Key pairs and Certificates, or only one or the other.

1.5 Policy Administration 1.5.1 Organization Responsibilities for this Certificate Policy The Experian Risk Management Committee is responsible for this Certificate Policy. 1.5.2 Contact Information Experian Information Security Office 475 Anton Boulevard Costa Mesa, CA 92626 Michael Kurihara [email protected] 714-830-5870 Telephone 714-830-2404 Facsimile 1.5.3 Notice and Publication The CA shall:

o Provide Subscribers, Designated Certificate Holders, and Relying Parties with the URL of a web site that contains the published version of this CP, digitally signed by an authorized representative of the CA;

o Ensure the published version remains updated consistent with the version approved by the Risk Management Committee;



o Provide, at its discretion to relevant parties, on such terms and conditions it deems appropriate, all or part of the CPS, for the purposes of any audit, inspection, accreditation or cross-certification.

1.5.4 Certificate Policy Amendment The Experian Risk Management Committee (RMC) may amend this Certificate Policy, or any part thereof, at any time at its discretion. Prior to any amendment of this Certificate Policy, the Experian RMC will provide notice of any proposed change in writing to all Certificate Authorities that are directly cross-certified with Experian, and may specify a comment period in any such notice. The Global Security Steering Committee (GSSC) shall maintain the list of cross-certified Certificate Authorities. In addition, notice shall be placed on the website mentioned in Section 1.5.3 above. 1.5.5 Certification Practice Statement Approval The Experian Information Security Office shall determine if a CPS sets out in a satisfactory manner how the CA will implement the requirements of this Certificate Policy, and recommend approval when appropriate to the Experian Risk Management Committee (RMC). The RMC shall approve the Certification Practice Statement and any amendments thereto.

1.6 Definitions and Acronyms 1.6.2 List of Definitions

Authority Revocation List: A list of revoked Certification Authority cross-certificates.

Activation Data: Data values, other than keys, that are required to operate cryptographic modules and that need to be protected (e.g., a PIN, a passphrase, or a manually-held key share).

CA Certificate: A certificate for a CA's public key, either self-signed or issued by another CA.

CA Private Signing Key: The private key corresponding to a Public Key listed in a CA Certificate and is used to sign digital certificates

Certificate: A digitally-signed document that is a public-key certificate in the version 3 format specified by ITU-T Recommendation X.509, which includes the following information: (i) Identity of the Certification Authority issuing it; (ii) the name or identity of its subscriber, or a device or electronic agent under the control of the subscriber; (iii) a Public Key that corresponds to a Private Key under the control of the subscriber; (iv) the validity period; (v) the Digital Signature created using a Private Key of the Certification Authority issuing it; and (vi) a serial number.

Certificate Revocation List (CRL): A list of certificates revoked prior to the expiration of their Validity Periods.

Certification Authority (CA): A legal entity that issues, signs, manages, and revokes Certificates and performs all functions related hereto, including identification, authentication, and revocation of subscribers, and vouches for the binding between the data items in a Certificate.

Certificate Policy (CP): A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. The CP addresses all aspects associated with the generation, production, distribution, applicability, recovery, and administration of a Certificate.

Certification Practice Statement (CPS): A statement of the practices and policies that a Certification Authority employs in issuing, managing, revoking, and renewing or re-keying certificates.

Cryptomodule: Either software, a device, or a utility that generates Key Pairs, stores cryptographic information, and/or performs cryptographic functions.

Designated Certificate Holder: An individual responsible for a certificate with a device or non-entity as the named subject.



Digital Signature, Digitally Sign: The transformation of a message using an asymmetric cryptosystem such that a person having the initial message and the signer’s Public Key can determine whether: (i) the transformation was created using the Private Key that corresponds to the Subscriber’s Public Key; and (ii) the message has been altered since the transformation was made.

Distinguished Name (DN): The unique identifier for a Subscriber so that s/he can be located in a directory based on the ITU/CCITT X.500 (e.g. the DN for a Subscriber might contain the following attributes: common name (cn), e-mail address (mail), Organization name (o), Organizational unit (ou), locality (l), state (st) and country (c)).

End Entity: The named subject in a certificate (e.g., a Subscriber or device) and any authorized Relying Party.

Experian Certificate: A certificate issued pursuant to the Experian CP.

Issue Certificates, Issuance: The act performed by a CA in creating a Certificate listing the CA as “Issuer,” and notifying the Applicant of the contents and that the Certificate is ready and available for Acceptance.

Issuing Certification Authority (Issuing CA): In the context of a particular certificate, the issuing CA is the CA that issued the certificate (see also Subject certification authority).

Key: A general term used to encompass any one of the cryptographic keys.

Key Generation: The process of creating a Key Pair.

Key Pair: Two mathematically related Keys (a Private Key and the corresponding Public Key), with the following properties:

1. one Key can encrypt a communication only capable of decryption by the other key; and

2. deriving or discovering one Key from the other Key is computationally infeasible, assuming likely circumstances including the availability of text encrypted by either of the keys.

Lightweight Directory Access Protocol (LDAP): A client-server protocol used for accessing X.500 directory services over a computer network.

Object Identifier (OID): The unique alphanumeric/numeric identifier registered under the ISO registration standard to reference a specific object or object class. In the PKS established by the Experian CP, they are used to uniquely identify Certificates issued under the CP and the cryptographic algorithms supported.

Online Certificate Status Protocol (OCSP): A protocol which is used to provide real-time validation of a certificate’s status. An OCSP responder is used to respond to certificate status requests and can issue one of three responses: Valid, Invalid, or Unknown. An OCSP responder replies to certificate status requests on the basis of CRLs (Certificate Revocation Lists) provided to it by Certification Authorities.

Operational Period: A Certificate’s actual term of validity, beginning with the start of the Validity Period and ending with the earlier of:

1. the end of the Validity Period disclosed in the Certificate, or

2. the revocation of the Certificate.

Private Key: The sensitive Key in the Key Pair protected by the Subscriber and kept secret. The Private Key creates Digital Signatures or decrypts data previously encrypted using the corresponding Public Key.

Public Key: The non-sensitive Key in the Key Pair disclosed by the Subscriber holding the corresponding Private Key. The Public key verifies Digital Signatures created using the corresponding Private Key, or encrypts data meant for decryption with the corresponding Private Key.

Public Key Cryptography: A type of cryptography also knows as asymmetric cryptography. This cryptography uses a Key Pair rather than a single key to secure the authentication and/or confidentiality of data.



Public Key Infrastructure (PKI): The architecture, technology, practices, and procedures that support operation of a security system employing Certificates and Public Key Cryptography.

Public Key Service (PKS): This is identical with Public Key Infrastructure, with the word Service used to emphasis on leveraging the environment to service clients and internal partners.

Relying Party: A recipient of a certificate who acts in reliance on that certificate and/or any digital signatures verified using that certificate. In this document, the terms "certificate user" and "relying party" are used interchangeably.

Repository: An online system maintained by an Issuing CA for storing and retrieving Certificates and other information relevant to Certificates, including information relating to Certificate validity or revocation.

Revoke (a Certificate): To invalidate a Certificate permanently from a specific time onward. Revocation includes listing the Certificate in a set of revoked Certificates or other directory or database of revoked Certificates (e.g. inclusion in a CRL). The system also prevents users from accessing revoked certificates once connected to the central infrastructure.

Request For Comments (RFC): Document series used as the primary means for communicating information about the Internet. Some RFCs are designated by the IAB as Internet standards. Most RFCs document protocol specifications such as Telnet and FTP.

Risk Management Committee (RMC): The Risk Management Committee serves as the governing body for all Information Security Policies and Standards throughout their lifecycle to provide continuous protection of Experian information infrastructure. Experian Business units may create local policies, standards and procedures to meet specific business unit needs as long as those policies, standards and procedures do not weaken or conflict with Experian Information Security Policies and Standards.

Secure Personal Security Environment (SPSE): A secure storage area containing information such as private keys and related certificates. The storage area is encrypted and protected using cryptography. The form of storage may vary from files to tamper-resistant cryptographic tokens

Subject Certification Authority: In the context of a particular CA-certificate, the subject CA is the CA whose public key is certified in the certificate (see also Issuing certification authority).

Subject Name: The specific field in a Certificate containing the Distinguished Name for the Subscriber.

Subscriber: An Experian employee, or an Experian partner:

• using an Experian Certificate solely for the purposes of furthering the business of Experian

• who is the subject named or otherwise identified in a Certificate

• who controls a Private Key that corresponds to the Public Key listed in that Certificate

• who is the individual to whom digitally signed messages verified by reference to such Certificate are to be attributed or whose identity is authenticated.

A web server:

• using an SSL Certificate which has been issued to an Experian owned domain

• who is the subject named or otherwise identified in a Certificate

• who controls a Private Key that corresponds to the Public Key listed in that Certificate

• who is the web server to whom digitally signed messages verified by reference to such Certificate are to be attributed or whose identity is authenticated.

Or



An Experian employee, or an Experian partner:

• using an Experian Certificate solely for the purposes of furthering the business of Experian

• who is a designated certificate holder for a role certificate, and

• who controls a Private Key that corresponds to the Public Key listed in that Certificate.

Subscriber Agreement: An agreement between a CA and a Subscriber that establishes the right and responsibilities of the parties regarding the issuance and management of certificates.

Token: A Cryptomodule consisting of a hardware object with memory and a microchip (e.g. a “smart card”).

Trusted Role: The execution of a Trusted Role requires adherence to policies and procedures to prevent the introduction of security problems. The functions of Trusted Roles form the basis of trust for the entire PKS.

Validity Period: The intended term of validity of a Certificate, beginning with the date of Issuance (“Valid From” or “Activation” date), and on the expiration date indicated in the Certificate (“Valid To” or “Expiry” date).

1.6.2 List of Acronyms

ARL Authority Revocation List CA Certification Authority CP Certificate Policy CPS Certification Practice Statement CRL Certificate Revocation List FIPS Federal Information Processing Standard LDAP Lightweight Directory Application Protocol OCSP Online Certificate Status Protocol OID Object Identifier PKI Public Key Infrastructure, also known as PKS PKS Public Key Services, also known as PKI RFC Request for Comment RMC Risk Management Committee SPSE Secure Personal Security Environment URL Uniform Resource Locator US United States



2 PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1 Publication and Repositories 2.1.1 Certificate Authority and Repository This Certificate Policy shall serve as the policy with regard to all Certificate activities throughout the lifecycle of the Certificate. This includes Certificate creation, transmission, use, protection and disposal among others. This Certificate Policy shall be made available to all users relying or placing trust in the Certificates issued under this Certificate Policy. Each issuing CA shall operate or cause the operation of a secure online Repository that is available to Authorized Relying Parties and that contains:

o issued Experian Certificates; o a CRL or online Certificate status database; o the Issuing CA’s Certificate for validating the CAs Signing Key; o a copy of this Certificate Policy; and o other relevant information required to establish trust relating to Experian Certificates.

The CA shall implement the following access controls to protect the repository:

o The CA shall ensure only authorized CA personnel may administer the CA’s repository or alternative distribution mechanism.

o The CA shall monitor the performance of the repository or alternative distribution mechanism. o The CA shall maintain the integrity of the repository or alternative distribution mechanism.

The Issuing CA shall not impose any access controls on:

o this Certificate Policy; and o the Issuing CA’s Public Certificate Authority Certificate.

The location of publication shall be appropriate to the internal Certificate-using community, in accordance with the security requirements established within the CPS, and will identify an X.501 directory and an LDAP interface. http://pks.experian.com

2.1.2 Revocation Information The sole source of information regarding the validity or revocation of an Experian Protection Certificate shall be provided by the issuing CA through the mechanisms specified in this Certificate Policy. In order to preserve trust in the PKS, the dissemination of information concerning the events leading up to an investigation of a revocation should be limited to those involved.

http://pks.experian.com/



3 IDENTIFICATION AND AUTHENTICATION

3.1 Naming 3.1.1 Types of Names Each Entity:

o Shall have Experian’s clearly distinguishable and unique x.501 Distinguished Name (DN) in the Certificate subject name field; and

o May assign an alternate name via the SubjectAlternativeName field. The DN must be in the form of a X.501 printable string and shall always be present. 3.1.2 Naming Clarity The Subject name in a Certificate shall be meaningful to the extent that a Business Unit has associated the Certificate with an End Entity. All Certificates shall contain the electronic mail address of the End Entity or the agent of this end entity. 3.1.3 Anonymity or Pseudonymity of Subscribers The CA does not support the use of pseudonyms in subscriber common names when sending email. Under typical legal frameworks devices, applications and roles cannot have legal names; therefore, the CA shall ensure that a record is retained of the person who owns the Certificate on behalf of the device, application or role. 3.1.4 Rules for Interpreting Various Name Forms Name forms shall comply with RFC 822 and X.500 standards for name forms. The Relative Distinguished Name (RDN) shall visibly identify the legal or organizational name of an End Entity. Legal names, organizational names, alphanumeric identifiers or hashes of any of the foregoing may be used as an RDN. 3.1.5 Uniqueness of Names Distinguished names must be unique for all End-Entities of the CA. The SubjectUnique Identifiers field, as defined in RFC 3280 – Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, used to differentiate Subscribers or Designated Certificate Holders with identical names, will not be supported. The CA shall make all decisions regarding Entity names in all assigned Certificates. A party requesting a Certificate may be required to demonstrate its right to use a particular name. The CA shall ensure that its agreement with the repository has a name claim dispute resolution procedure in the event there is a dispute about a name in a repository not under its control. 3.1.6 Recognition, Authentication and Role of Trademarks Where permitted or required, the use of a trademark is reserved to the holder of that trademark.

3.2 Initial Identity Validation



3.2.1 Method to Prove Possession of Private Key Prior to issuing a verification Certificate or exchanging private decryption Keys, the CA and End Entity shall confirm their possession of the corresponding Private Key in a secure manner as described in the CPS. 3.2.2 Authentication of an Organization Identity A device Certificate shall always be tied directly to a Designated Certificate Holder acting on behalf of the organization. If this individual separates from the organization, a new device Certificate shall be issued to reflect the new agent of the company. The authentication procedures ensure the validity of the organization. The authentication of the organization’s identity must use the following procedures:

o Privately shared information if the identity of the organization has been previously established by a Business Unit for enrollment purposes; or

o Copies of official documentation demonstrating the legal existence of the organization. The CA or RA must also verify the identity and authority of the individual and that individual’s authority to receive the Keys. The CA or RA shall maintain a record of the means uses to establish the identity of the organization and individual authorized to act on behalf of the organization, and any type of identification used, and shall maintain a copy of the identification evidence for three (3) years. 3.2.3 Authentication of an Individual Identity Individual Authentication The authentication procedures ensure the validity of the individual’s authority to request a Certificate. The authentication of the individual’s identity may use either of the following procedures:

3.2.3.1 Establish identity through a Subscriber initiated process that involves authentication to an internal web site., or

3.2.3.2 The use of Experian Two-factor authentication mechanisms based on the identity authentication mechanism described above in Section 3.2.3.1

Additional Restricted Certificate Requirements:

3.2.3.3 Experian Restricted Certificates shall additionally require two forms of Government Identification and the

Experian employee badge presented to the local Information Security office in person. One form of identification must include a picture.

The CA or RA shall ensure that a record is kept of the means by which the identity of the individual has been established, and of any type of identification used, including the unique number assigned to each ID (e.g., driver’s license number). Organizational Representatives for Cross Certification In the case of cross-certification, requests with representatives of external entities, the address of record shall be the Sales database. This address shall be validated against public record to ensure the address is a formal business office of the entity. Requests for Certificates on behalf of organizations shall only be submitted by an individual authorized to act in this capacity as an agent of the company. These Certificates are intended solely for cross-certification purposes, and shall not function in any other role outside Experian’s environment.



The CA or RA shall ensure that a record is kept of the means by which the identity of the individual has been established, and of any type of identification used, but is not obligated to retain a copy of the actual identification evidence. Devices or Applications Upon issuance, the Certificate shall be assigned to an individual serving as a Designated Certificate Holder who will be responsible for the use of the Certificate. The following information is required for authenticating these requests:

o The user shall follow the standard Individual Authentication mechanism stipulated in this Section to establish their identity. Alternatively, if this user already has an Experian Certificate issued in compliance with this requirement, they may submit a digitally signed request.

o Equipment (e.g., serial number) or application identification (e.g., DNS name); o Equipment or application Public Keys; o Equipment or application authorization and attributes (if they are to be included in the Certificate); and o Contact information to enable the CA or RA to communicate with the Designated Certificate Holder.

The CA or RA shall ensure that a record is kept of the means by which the identity of the Designated Certificate Holder has been established and of any type of identification used and shall retain a copy of the actual identification evidence.

3.3 Identification and Authentication for Re-Key Requests All changes to information in Certificates shall be verified by the CA or RA authorized to act on behalf of the CA. This verification shall occur prior to issuing the Certificate, except where the CA initiates multiple changes to the DNS or Subscribers as part of organizational changes. 3.3.1 Identity Management for Routine Re-Key Only the individual or authorized representative of an entity may request a re-Key transaction. The entity or individual requesting re-Key may authenticate using their valid Digital Signature Key pair. Where a Key has expired, the request for Re-Key shall be authenticated in the same manner as initial registration. Requests for all Re-Keys shall be recorded in a log, with the status of the request. See Section 4.7 for Re-Key requirements. 3.3.2 Identity Management for Re-Key after Revocation In any situation where a threat to the integrity of the Private Key is suspected, the CA shall authenticate a Re-Key in the same manner as initial registration. See Section 4.7 for Re-Key requirements. 3.3.3 Re-Key upon Recovery Request Key recovery may be performed through an automated process. Requests for recovery of Private Key material shall be logged with the outcome of the request. In addition, a notification of the requests for recovery shall be sent to the mail address of record (traditional or electronic mail address). A Key Recovery request shall result in a Re-Key of the Subscriber’s Certificate.

3.4 Identification and Authentication for Suspension and Revocation Requests The entity requesting revocation may authenticate the request using its private signing Key, regardless of whether or not the private signing Key has been compromised. A signed revocation request may be sent to the CA or RA for validation.



The CA shall establish and make public the process for validating these requests. The entity may also use an automated process of revocation through an internal web server, utilizing authentication as in Section 3.2.3.1. If the Private Key is not available for signing a revocation request, the end entity may submit a request, with the approval of their immediate management for revocation. The Certificate shall be suspended prior to receiving the approval from management and remain suspended until the identity of the requesting user is established, and revoked once the individual’s full identity is established. Section 4.9.2 describes additional requirements for revocation of a Certificate. Requests for revocation of Certificates must be recorded in a log, and meet the requirements for audit logging established in Section 5.4.

3.5 Identification and Authentication for Recovery Requests See Section 3.3.3 Re-Key upon Recovery Request.



4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1 Certificate Application The CA shall:

o Clearly document all procedures and requirements with respect to the process for applying and receiving Certificates.

Bulk applications for Certificates are allowed, but this process still requires authentication as required in Section 3.2 and shall be approved by the Information Security Office.

4.2 Certificate Application Processing For each Certificate application the CA or RA shall follow the authentication requirements described in Section 3 above for establishing identity.

When requested by the CA or RA, the Certificate applicant shall show proof of authorization for any requested Certificate or Certificate attributes. The CA or RA shall ensure that terms and conditions of use govern each Certificate it issues. Subscribers shall enter into a subscriber agreement or otherwise be subject to terms and conditions concerning their rights, privileges and obligations associated with Certificates issued to them. When submitting an application for Designated Certificates, the representative of the applicant company shall refer to the name of the Business Unit, the date of execution of the agreement or any contract identifier to indicate the agreement their organization signed concerning its rights, privileges and obligations associated with Certificates issued, or to be issued, to Designated Certificate Holders on behalf of the Business Unit. Subject to any written agreement, an application for a Certificate does not, in any way, obligate the CA or RA to issue a Certificate. The CA or RA may refuse to issue Certificates for any reason, as defined within the Certification Practice Statement (CPS). 4.2.1 Digital Signature Requirements Each application shall be accompanied by a public verification Key generated by or on behalf of the Subscriber or Designated Certificate Holder. 4.2.2 Application for Cross-Certification Any request by another CA to cross-certify shall solely be addressed by the Risk Management Committee. An application for cross-certification shall not obligate the CA to issue a cross-Certificate.

4.3 Certificate Issuance Certificates shall only be issued after the authentication and authorization of the potential Subscriber is completed by the CA. The process for issuing a Certificate includes, issuing the Certificate, notifying the applicant, and making the Certificate available for the Subscriber to accept. The user shall be notified via e-mail once their Certificate is issued, unless issued electronically through the Self Administration Server.



Certificates may also be issued automatically through the Self Administration Server. The server will authenticate as per Section 3.2.3.1. Experian Certificates are classified as restricted. Experian Certificates shall be protected during transmission and loaded directly into the Certificate repository on end points. The public portion of the Certificate shall be published to an internal directory available to users.

4.4 Certificate Acceptance Acceptance of the Certificate by the End Entity shall indicate agreement by the End Entity to comply with all the provisions described in this Certificate Policy and all obligations associated with use of the Certificate. Acceptance shall occur when the user brings the Certificate into their local Certificate store for use, or upon the initial use of the Certificate. Possession of an Experian Certificate shall within five (5) minutes trigger acceptance of pending Certificates and the subscriber agreements.

4.5 Key Pair and Certificate Usage 4.5.1 Subscriber Responsibilities The Subscriber or Designated Certificate Holder shall only use the Certificates issued to them for appropriate applications as set forth in this Certificate Policy and as stipulated in the Key usage field. Use of a Private Key and Certificate are subject to the terms of the subscriber agreement, the use of the Private Key is permitted only after the subscriber has accepted the corresponding Certificate. The Subscriber must discontinue use of the Private Key after expiration or revocation of the Certificate. Failure to comply with this Certificate Policy or subscriber agreement shall result in disciplinary actions up to and including termination. 4.5.2 Relying Party Responsibilities The relying party is obligated to only use Certificates for the appropriate applications set forth in the CPS and as stipulated in the Key usage field. The relying party shall verify the status of Certificates using one of the required or permitted mechanisms set forth in the CP (see Section 4.4.9 below). The relying party assents to the terms of the applicable relying party agreement as a condition of relying on the Certificate. 4.5.3 Experian Restricted Certificate Usage Additional Restricted Certificate Requirements: Experian Restricted Certificates shall be issued for a specific use. Certificate extensions used by certificates issued under this Certificate Policy shall conform to the applicable parts of RFC 3280 – Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. One example could be Restricted Certificates issues to legal personnel to protect legal materials.

4.6 Certificate Renewal 4.6.1 Criteria for Certificate Renewal Certificates shall be Re-Keyed in place of renewals. The criteria for Re-Key shall be followed for Certificate Re-Key under Section 4.7.



o

4.6.2 Certificate Renewal Authentication Certificates shall be Re-Keyed in place of renewals. The criteria for Re-Key shall be followed for Certificate Re-Key under Section 4.7.

4.7 Certificate Re-Key Certificates are Re-Keyed periodically to minimize the risk of attacks on the underlying encryption. Re-Keying of a Certificate involves changing the controls that drive the encryption used for signing and/or protecting data. A Certificate Re-Key shall occur after a Certificate has been suspended or revoked for any reason. In addition, a Certificate shall be Re-Keyed upon the renewal of the Certificate. 4.7.1 Certificate Re-Key Authentication The CA shall:

o Authenticate all renewal requests as described in Section 3.3; and o Record and retain all information regarding the request and the status.

A Re-Keyed Certificate shall follow the provisions for Certificate Acceptance established in Section 4.4 above.

4.8 Certificate Modification A Certificate shall be modified if a subject’s legal name changes, their functional role changes and the Certificate use are no longer authorized, or a reorganization change initiates a DN change. A modification may be authorized by the Subscriber, human resource personnel, the CA or the Registration Authority. The procedures for issuing modified Certificates shall follow the procedures for Certificate Re-Key. A notification shall be sent to the Subscriber upon issuance of Certificates, with the exception of transferring Designated Certificate Holders. A transfer of Designated Certificate Holders may trigger a change to the identifying information with the new Designated Certificate Holder’s information and the new subscriber shall change any passwords protecting the Certificate. A modified Certificate shall follow the provisions for Certificate Acceptance established in Section 4.4 above.

4.9 Certificate Revocation and Suspension In the event of a compromise or suspected compromise of an Entity’s decryption or signing Private Key, the Entity shall notify the CA within five (5) minutes. In the event of a compromised CA signing Key, the CA shall within five (5) minutes notify all CAs with whom cross-certification has been established, and comply with the requirements in Section 5.7.2 below. 4.9.1 Criteria for Revocation Certificates shall be revoked if any of the following criteria are met:

o Information in the Certificate changes, unless authorized as a Certificate modification under Section 4.8; o The suspected or known compromise of the Private Key or media holding the Private Key; o A request is received from the immediate management of the Subscriber, or the Business relationship owner for

Certificate issued for cross-certification. o Upon the termination of employment of an individual Subscriber; o Upon the change of duties to no longer require access to a Private Key, or

Receipt of a properly authenticated request to revoke a Certificate.



The CA may revoke a Certificate if an entity fails to comply with any agreement, or the Subscriber has not used their Private Key over the past six (6) months, or where the CA reasonably believes the appropriate action is revocation. The CA shall notify users after any revocation occurs. 4.9.2 Revocation Authentication The CA shall:

o Authenticate all revocation requests as described in Section 3.4; o Record and retain all information regarding the request and the status; o Publish notice of the revocation in the appropriate CRL, or OCSP server; and o Publish notice of the revocation of a cross-Certificate in the appropriate ARL or OCSP server.

4.9.3 Grace Period for Revocation Requests The following time periods will govern the time allowed for executing authorized revocation requests:

o Within sixty (60) minutes during regular business hours for the CA. Once the administrator receives the notification, they shall take action to achieve the revocation; and

o Within sixty (60sixty60) minutes at the start of the next business day, when received outside normal business hours.

Additional Restricted Certificate Requirements:

o No later than eight (8) hours if the request is received outside of business hours.

4.9.4 Criteria for Suspension The CA shall temporarily revoke a Certificate upon the suspected compromise of the Private Key or media holding the Private Key. The CA may suspend a Certificate if an Entity fails to comply with any agreement, or the Subscriber has not used their Private Key over the past six (6) months, or where the CA reasonably believes the appropriate action is suspension. The CA shall notify users within five (5) minutes after any suspension occurs. 4.9.5 Authorization for Requesting Suspension A Certificate may remain suspended for a maximum of 30 calendar days. A temporary revocation of a certification may only be requested by:

o A Subscriber or Designated Certificate Holder; o Authorized BISO; o An RA on behalf of a any of the above personnel; o An automated process action on behalf of the CA; o The Chief Information Security Office, or Business Information Security Office

A permanent revocation may be requested by anyone if the Private Key is compromised. Section 3.4 establishes the requirements for authentication of these requests. Use of the compromised Private Key to sign the request meets these requirements. 4.9.6 Suspension Request Procedures The CA Shall:



o Authenticate all requests for temporary revocation of Certificates as described in Section 3.4 and the CPS; o Record and retain all information regarding the request and the status; and o Publish notice to the appropriate CRLs or OCSP servers of the revocation.

4.9.7 Suspension Period Limits The CA may terminate the temporary revocation of a Certificate once a determination by the Information Security Office is made that the temporary revocation was unfounded or a decision is made to revoke the Certificate. 4.9.8 CRL Issuance Frequency The CA shall issue and up-to-date CRL at least every twenty-four (24) hours, and where feasible every eight (8) hours. The CA shall ensure the CRL issuance is synchronized with all relevant repositories to permit a Relying Party to access the most recent CRL. In the event of an actual or suspected Key compromise, the CA shall issue an up-to-date CRL within sixty (60sixty60) minutes upon the revocation of a Certificate. 4.9.9 Subscriber CRL Checking Requirements A Relying Party shall:

o Verify the validity of all Certificates in the Certificate validation chain against the current CRLs and ARLs prior to relying on such Certificates; and

o Verify the authenticity and integrity of CRLs and ARLs.

4.10 Certificate Status Services 4.10.1 On-one Revocation and Status Checking The CA does not currently support OCSP. 4.10.2 Subscriber OCSP Revocation Checking Requirements No stipulation 4.10.3 Other Forms of Revocation Advertisements No stipulation 4.10.4 Checking Requirements for Other Forms of Revocation Advertisements No stipulation

4.11 End of Subscription The Subscriber shall have a mechanism for notifying the CA to end subscription of their CA services. This shall follow the process for Key revocation outlined above in Section 4.9. The CA shall assume termination of service if the expiration period is reached and no request for renewal is received with thirty (30) days.

4.12 Key Escrow and Recovery



A backup of all Experian data protection Keys shall be maintained by the issuing CA. Authentication shall follow the process outlined above in Section 3.2, prior to allowing a Subscriber to recover their Private Key. The CA shall record and retain all information regarding the recovery request and the status of such recovery.

4.13 Customer Service The CA shall integrate support for the issuance and use of Certificate technology into existing help desk functions with appropriate escalation paths. Formal change problem management shall be used to capture all issues and changes made to the PKS environment. The customer support help desk shall receive training for assisting clients with the public portion of Experian Certificates.



5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

5.1 Physical Security Controls Administrative access shall be restricted to only personnel with a role established within this Certificate Policy. The BISO shall oversee all administrative access. 5.1.1 Site Location and Construction The site hosting the CA services, including automated registration authorities, shall meet the Physical and Environmental Security (Key Control 4) requirements for restricted physical access as described in the Experian Information Security Policy. For non-automated Registration Authorities the workstation for processing requests shall operate in a data center, or in an Experian office area while attended. If located in a reception area, all RA media and access shall remain physically protected except when in use. The system and media shall be secured after each registration transaction, unless another transaction follows within five (5) minutes. 5.1.2 Physical Access Access to the CA hardware and software shall require dual authorization to gain physical access and ensure unescorted access to the CA hardware and software is only allowed for a defined list of approved personnel with operational responsibility for CA activities. Business Information Security Office shall maintain the list of approved personnel. Other personnel shall obtain authorization from the Information Security Office. Once these personnel obtain authorization, a representative from the Information Security Office shall escort and supervise these personnel at all times. Around the clock video surveillance shall monitor all equipment hosting CA services and functionality. The approved information security personnel shall maintain an access log and inspect this log weekly. The actual review of the log shall be recorded as well for audit purposes. A two-factor safe shall be used to store removable media and paper containing sensitive plain text information. Where a Personal Identification Number (PIN) or password is documented, this information must be stored in a dual access security container accessible only by the authorized personnel. All administrative users shall lock their workstations when unattended and lock the cryptography when not in use. Additional Restricted Certificate Requirements: Subscribers or Designated Certificate Holders must not leave their workstations unattended when the cryptography is in an unlocked state (i.e. when the PIN or password has been entered). A workstation that contains Private Keys on a hard drive must be physically secured and protected with an appropriate smart-card or hardware security token for Key storage as designated in Section 6.2 5.1.3 Power and Air Conditioning The CA shall ensure the power and air conditioning facilities are sufficient to support the operation of the CA system. 5.1.4 Water Protection The CA shall ensure that the CA system is adequately protected from water exposure by a water detection and remediation architecture. 5.1.5 Fire Prevention and Protection



The CA shall ensure that the CA system is adequately protected from fire by a fire suppression and detection system. 5.1.6 Media Storage The CA shall ensure that the storage media used by the CA system is protected from environmental threats such as temperature, humidity and magnetism. 5.1.7 Waste Disposal The CA shall ensure that all media containing confidential or higher information is sanitized, to remove information such that data recovery is not possible, or destroyed before release for disposal. The Business Information Security Office (BISO) shall account for the destruction of confidential or higher information. 5.1.8 Off-site Backup The BISO shall ensure that off-site backup and archival facilities meet the same level of security as the primary CA site, and all the appropriate protections for temperature, humidity, and magnetism. Transport and/or transmission of material for backup and archiving from the CA to the off-site back-up facility shall be done securely.

5.2 Procedural Controls 5.2.1 CA Trusted Roles The CA shall systematically separate the duties for critical CA functions to prevent one person from maliciously using the CA system without detection. Each user’s and administrator’s access shall only allow the actions they require to fulfill their responsibilities defined in policy and procedures. Three distinct personnel roles shall distinguish between (i) day-to-day operations of the CA system; (ii) the management of those operations; and (iii) the management of substantial changes to system requirements including policies, procedures or personnel. These trusted roles are defined here as:

o PKS Master User o PKS Officer o PKS Administrator

All personnel shall support the charter of activities describe within Section 1.3.1 and the body of this Certificate Policy. Alternative divisions of responsibilities may achieve the same level of resistance to “insider attack.” These alternatives require the review and approval of the Chief Information Security Office. Only the PKS Master User and personnel responsible for operational maintenance of the hardware, and operating system software shall have access to the software that controls the PKS system. This encompasses local and remote access. Compliance audits and other inspections are described in Section 8. 5.2.2 RA Trusted Role The BISO shall educate and build controls to ensure RA personnel understand their responsibilities. Specific areas of focus include identification and authentication of potential Subscribers or Designated Certificate Holders. One trusted individual may perform all RA functions, if a non-automated registration process is used. 5.2.3 Dual authorization Tasks Accessing Subscriber Certificate Private Keys stored on the CA requires two administrators. The CA may permit Subscribers to securely initiate their own Key recovery or Certificate revocation activities. All activities shall follow the authentication requirements established in Section 3.



Dual authorization is also required for CA Key generation as outlined below in Section 6.2.2. Single, trusted personnel may perform other non-sensitive functions. The CPS (Technical Security Baselines) document shall specify the exact activities requiring dual Key authorization. 5.2.4 Identification and Authentication for Each Role All BISO shall complete their identity and authorization verification process prior to:

o Granting access to the CA software, network and physical sites; o Issuing a Certificate for their CA role; and o Receiving an account in the PKS system if an account is required.

Any accounts created for CA personnel shall be directly attributable to one, and only one, individual. Sharing of Certificates issued to CA personnel is specifically prohibited. These accounts shall be kept private to this individual, and shall only be used to perform authorized activities assigned to the CA personnel holding this Certificate. Following these requirements represents a baseline requirement. Deviations from these requirements shall require action of the offending subscriber’s management, and the BISO, up to and including revocation of all CA permissions or termination of employment. The CA shall enforce these requirements through the use of CA security controls and operating system software and procedural controls.

5.3 Personnel Controls Personnel performing services for the CA or RA other than employees of Experian shall enter into employment contracts and acknowledge the terms and conditions of their engagement. Such terms and conditions of employment shall include a requirement to keep sensitive CA security relevant information protected and confidential. Additional duties assigned to BISO shall avoid any conflict of interests with their CA or RA duties (i.e. audit activities for the CA shall be separated from operational duties). 5.3.1 Qualifications, Experience, and Clearance Requirements All staff performing CA and RA functions shall possess the necessary knowledge, experience and qualifications to perform their duties. In addition, they must demonstrate a strong history of trusted performance of responsibilities. All CA and RA personnel shall go through an extended background check, including a criminal background check and a credit check as described in the Human Resource Policy Number 2. 5.3.2 Background Check Procedures All background checks shall comply with the CISO requirements for criminal background checks. 5.3.3 Training Requirements Personnel shall receive appropriate training including security requirements, operational responsibilities, and associated procedures. All BISO shall complete their Information Security Awareness training prior to receiving access to production systems. 5.3.4 Retraining Frequency A yearly review and update of the training program shall occur to accommodate changes to the CA system. Personnel shall re-certify this training annually by either retaking the course or helping revise the content. 5.3.5 Job Rotation Frequency No Stipulation



5.3.6 Sanctions for Unauthorized Actions Following the requirements established in this Certificate Policy represents a baseline. Deviations from these requirements shall require action of the offending subscriber’s management, and the BISO, up to and including revocation of all CA permissions or termination of employment. Formal investigation of potential deviations shall be executed in compliance with policy violation handling procedures defined by the Chief Information Security Office (CISO). 5.3.7 Independent Contractor Requirements Contract personnel must follow the same requirements as internal employees with regard to appointment, training, and background checks. Contract personnel shall not have access to set, restore, or control CA Policy or CA Security Policy. Contract personnel shall not have access to sign Cross Certificates or import certificate definitions or specifications. 5.3.8 Documentation Supplied to Personnel The CA shall supply personnel with the relevant Certificate Policies, Certification Practice Statements, Technical Security Baselines, as well as specific statutes, policies or contracts relevant to their positions as BISO, RAs, and Designated Certificate Holders. These documents shall be handled appropriately, based on their security classification, and returned to the BISO upon termination of CA related responsibilities.

5.4 Audit Logging Procedures 5.4.1 Event Capture Criteria The infrastructure shall maintain audit log files for all events relating to the security of the CA system, including, without limitation: network devices, directories, and servers hosting CA and RA software. All security audit capabilities of the CA operating system and CA applications shall be enabled. A subset of the critical events shall send alerts to BISO when the event occurs. Logs shall be maintained for six (6) years. Monitored events include, but may be extend beyond the following:

o System start-up and shutdown; (Alert) o CA application start-up and shutdown; (Alert) o Attempts to create, remove, set passwords or change the system privileges of the PKS Master User, PKS

Officers and PKS Administrators; (Alert) o Changes to CA details and/or Keys; (Alert) o Changes to Certificate creation policies (e.g. validity period); o Login and logout attempts (both successes and failures); o Unauthorized attempts at network access to the CA system; o Unauthorized attempts to access system files; (Alert) o Generation of CA and subordinate entity Keys; (Alert) o Creation and revocation of Certificates; o Attempts to initialize, remove, enable, and disable Subscribers, as well as attempts to update and recover their

Keys; and o Failed read-and-write operations on the Certificate and CRL directory.

All logs must contain the date and time of the event and the identity of the entity that caused the event. Electronic logs shall use the standard time synchronization servers, and all time recorded in Greenwich Mean Time (GMT), and local time. The CA shall also collect either electronically or manually, security information not generated by the CA infrastructure directly, including:

o Physical access logs; o System configuration changes and maintenance; as defined in the CPS (Technical Security Baselines); o BISO changes;



o Incident response reports o Evidence on the destruction of confidential or higher information o Current and past versions of all Certificate Policies o Current and past versions of all Certification Practice Statements (Technical Security Baselines for PKS

Services) o Vulnerability Assessment Reports o Information Security Risk Analysis Reports o CA Certification and Accreditation Reports o Compliance Inspection Reports; o Current and past versions of user Agreements and other binding agreements with Subscribers; and o All maintenance repairs and results of diagnostic tests

The CPS (Technical Security Baselines) shall indicate the specific information to be logged. Experian designates this as the Public Key Service, and shall define a Statement of Direction, service metrics and monitor the performance of these activities appropriately. All agreements and correspondence relating to CA services shall be collected and consolidated in a single location. Where possible, this information shall be digitally signed with a Certificate. 5.4.2 Frequency of Audit Log Processing Log reviews shall occur weekly and a summary of significant events reviewed and documented at least once every week. Such reviews involve verifying the integrity of the log digital signatures and then inspecting all log entries. The BISO shall conduct a more thorough investigation of any “alerts” or irregularities in the logs. The CPS (Technical Security Baselines) shall indicate the roles with responsibility for audit log review and preparation of review summaries for management. The CA shall document any actions taken following these reviews, and archive these documents and their respective findings for six (6) years. 5.4.3 Retention Period for Audit Logs Logs shall be retained online for at least six (6) years and subsequently retain audit logs generated by the PKI software as described in Section 5.5. Information Security shall serve as the Information Steward for all log material. 5.4.4 Protection of Audit Log Access to logs shall be protected according to the requirements established within the CPS. The BISO shall enforce the policies protecting the audit logs. 5.4.5 Log Backup If logs are maintained in paper form, the CA shall make copies of all logs and summaries and store these backups at an alternate secure location. 5.4.6 Audit Collection System The CA shall use an electronic audit collection system. This system shall be defined within the CPS (Technical Security Baselines). 5.4.7 Subject Notification of Events The CA reserves the right to inform Certificate subjects when an event is logged by the audit collection system. When the trust of the Subject Certificate has been damaged, the CA shall provide notice to the individual, organization, role, device or application Subject within twenty-four (24) hours, and when possible within four (4) hours. 5.4.8 Vulnerability Assessments



The BISO shall ensure that a vulnerability assessment is performed every sixty (60) days, reviewed and revised following an examination of these monitored events and shall take appropriate action to minimize identified system vulnerabilities as soon as reasonably possible. Service Level Agreements and Objectives shall ensure the CA is provided with a weekly opportunity to make any significant changes associated with vulnerability remediation.

5.5 Records Archival Certificates, cross-Certificates, and CA (self-signed) Certificates, ARLs, and CRLs generated by the CA, must be retained for at least six (6) years after the expiration date listed on each. The CA shall retain audit information, as defined in Section 5.4, for a period defined in the CPS (Technical Security Baeslines), subject to the following requirement to retain information for at least six (6) years:

o Audit logs generated by the PKI CA software; o Subscriber agreements; o Records pertaining to identification and authentication information; o Physical access logs; o System configuration changes and maintenance; as defined in the CPS (Technical Security Baselines); o BISO changes; o Incident response reports; o Evidence on the destruction of confidential or higher information; o Current and past versions of all Certificate Policies; o Current and past versions of all Certification Practice Statements (Technical Security Baselines for PKS

Services); o Vulnerability Assessment Reports; o Information Security Risk Analysis Reports; o CA Certification and Accreditation Reports; o Compliance Inspection Reports; o Current and past versions of user agreements and other binding agreements with Subscribers; and o Evidence of training personnel received relating to CA training.

Private Keys used to decrypt data shall be protected at a level of physical and cryptographic protection equal to or exceeding that in place at the CA site. These Keys shall be retained for the lifetime of the data being protected. A second copy of all material retained may be stored in a location other than the CA site, and must be protected by physical security with access restricted to authorized BISO. Any secondary site must provide adequate protection from environmental threats such as temperature, humidity and magnetism. All confidential or restricted data shall receive strong encryption prior to leaving the operational CA environment for archival. All backups created shall go through a verification step to ensure the destination tape matches the source data. 5.5.1 Release of Information Records of individual transactions may be released upon request of any entities involved in the transaction and their legally recognized agents. The CISO office must approval all requests for the release of information internally. The CISO office must approval all release of information to outside parties. Compliance inspection reports shall not be made public unless required by law pursuant to judicial authorization or an express statutory requirement or by an agreement.

5.6 Key Changeover To minimize risk from compromise of a CA's private signing Key, that Key may be changed periodically; from that time on, only the new Key shall be used for Certificate signing purposes. The old, but still valid, Certificate shall be available to



verify Certificates signed using the associated Private Key. If the old Private Key is used to sign CRLs that contain Certificates signed with that Key, then the old Key shall be retained and protected.

The CA shall publish a new Certificate after Key changeover and make it available to Subscribers as stipulated in Section 6.1.4.

5.7 Compromise and Disaster Recovery 5.7.1 Resource or Data Availability The CA shall state in the CPS (Technical Security Baselines), or other appropriate documentation, the steps to be taken in the event of data corruption, data loss, loss of computing resources, and/or software. Where a repository holding Experian Certificates is under the control of a third party, the CA shall ensure the agreements and arrangements with the repository establish and document procedures to address the corruption or loss of the repository’s computing resources, software and/or data. 5.7.2 CA Public Certificate Revocation In the unlikely event of a need for revocation of a CA Certificate, the CA shall within five (5) minutes initiate notification to:

o The Risk Management Committee; o All CAs to whom cross-Certificates have been issued; o All of the CA’s Registration Authorities; o All the Subscribers; and o All Business Units of Experian

The CA shall publish the Certificate serial number on an appropriate Authority Revocation List (ARL), as defined within the CPS. The CA shall also revoke all cross-Certificates signed with the revoked CA Certificate. The CA shall request revocation of cross-Certificates issued to the CA, and revoke all Certificates issued using that Key. After performing a primary cause analysis and remediation, the CA may generate a new CA signing Key pair and re-issue Certificates to all Entities, ensuring that all CRLs and ARLs are signed using the new Key. The CA shall indicate in the CPS (Technical Security Baselines) or in a publicly available website the details of how notice shall be provided of the CAs Public Key revocation. Section 2.1.1 contains the URL to the website 5.7.3 Business Continuity Capabilities The CA shall prepare and maintain a business continuity plan outlining the steps taken to re-establish a secure facility in the event of a natural or other type of disaster. This plan shall follow the standard Experian format for documenting business continuity plans. The plan shall address at minimum the following areas:

o A definition of roles and responsibilities for those executing various components of the recovery plan; o The conditions for activating the plan, describing the process to be followed before the plan is activated; o Fallback procedures, describing the actions to be taken to move essential business activities or support services

to alternate locations, and to bring business processes back into operation in required time-frames; o Resumption procedures, describing the actions to be taken to return to normal business operations; o A testing schedule, specifying how and when the plan will be tested, as well as the process for maintaining the

plan; and o Awareness education activities designed to create understanding of the business continuity processes and

ensure the process remains effective.



Where a repository is hosted in a non-Experian owned site, the CA shall establish the appropriate agreements and arrangements to document a business continuity plan in compliance with these requirements.

5.8 CA Termination/Change in Operations In the event the CA ceases operation or makes a major change in policy or operations, the CA shall notify the constituents listed in Section 5.7.2. Such notice shall occur 30 days prior to or within five (5) minutes upon the termination of operations or the major change. Notice shall be sent via electronic mail where possible, and in writing for the remaining constituents. In the event the CA ceases operations, the CA shall comply with all requirements for retention in accordance with the archival requirements specified in this Certificate Policy. The CA shall also arrange for the future retention of any data (e.g. passwords or PINs) required to ensure that CA records are accessible for six (6) years.

5.9 Customer Service The CA shall integrate support for the issuance and use of Certificate technology into existing help desk functions with appropriate escalation paths. Formal change problem management shall be used to capture all issues and changes made the environment. The customer support help desk shall receive training for assisting clients with the public portion of Experian Certificates.



6. TECHNICAL SECURITY CONTROLS

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation

Each End Entity shall generate and store their own signing Key pairs in a cryptographic module that meets the requirements identified in Section 6.2.1. The CA shall generate encryption Key pairs for End Entities.

CA Key Generation

The BISO shall ensure that CA Key generation shall be: o Performed by personnel in trusted roles under, at a minimum, dual control; o Carried out within a hardware cryptographic module that satisfies the requirements identified in Section 6.2.1 or

higher; and o Performed using an Experian Information Security approved algorithm in accordance with Section 6.3.

The BISO shall document the CA Key generation procedures and generate auditable evidence that the documented procedures are followed.

RA Key Generation

The CA shall ensure that RA Key generation shall be: o Carried out within a device which satisfies the requirements identified in Section 6.2.1 or higher; and o Performed using an Experian Information Security approved algorithm in accordance with Section 6.3.

Subscriber/Designated Certificate Holder Key Generation

Each digital Key pair must be generated using an Experian Information Security approved algorithm.

Key pairs, other than the CA, may be generated in a software or hardware cryptographic module that satisfies the requirements identified in Section 6.2.1.

6.1.2 Key Delivery to Subscriber A Private Key shall not appear outside of the module it was generated in, unless it is encrypted. The encrypted Private Key may be output for local transmission or for storage by a Key recovery mechanism.

Private signature Keys shall be generated and remain within the cryptographic boundary of the cryptographic module.

In those cases where Subscriber Key pairs (other than signature Keys) are generated by the CA on behalf of the Subscriber, the Private Key shall be delivered to the Subscriber using a delivery mechanism that provides authentication and confidentiality commensurate with the strength of the cryptography offered by the Key.

6.1.3 Key Delivery to Certificate Issuer Where the Subject generates the digital signature Key pair, the CA shall arrange for receipt of the public verification Key. The method shall be documented in the CPS (Technical Security Baselines). 6.1.4 CA Public Key Delivery to Subscribers



.2 Private Key Protection and Cryptographic Module Engineering Controls

ubscribers and Designated Certificate Holders must satisfy the

igital Signature Key generation, CA Digital Signature Key storage and Certificate signing operations must be performed in a hardware cryptographic module rated as specified in FIPS 140-1 or

ce.

ture Key generation and signing operations must be performed in a hardware cryptographic module rated to at least FIPS 140-1 or FIPS 140-2 Level 1 or otherwise deemed to

all at

The CA shall deliver the CA public verification Key to Subscribers in the form of CA Certificate formatted according to the profile defined in Section 7.1.

6.1.5 Key Sizes

The CA shall use a 2048-bit RSA algorithm for its own CA signing Key pair. Where possible, End Entities shall use 1024-bit RSA for their Key pairs. Where this is not feasible, End Entities document a business case to use other than 1024 bits RSA for their Key pairs. The business case shall be reviewed and approved by the Chief Information Security Officer.

6.1.6 Public Key Parameters Generation and Quality Checking

No stipulation.

6.1.7 Key Usage Functions Digital Signature Keys shall support authentication and data integrity for non-repudiation. Only CA signing Keys shall sign Certificates issued by the CA and the signing of CRLs. Subscriber’s data protection Keys shall support the secure exchange and storage of symmetric Keys used for session and data confidentiality. This Certificate policy shall support two classifications of Certificates for enhancing security. This classification is founded in the policy titled Experian Confidential Certificates, and Experian Restricted Certificates. The Certificates issued under this Certificate Policy are intended for the following two types of services:

Experian Confidential Certificates: Protection of “Experian Confidento ial,” and “Experian Internal” data.


Protection of any classifico ation of data under the Experian policy up to and including “Experian Restricted.” Protection ofo automated product transactions containing credit data.

The KeyUsage field shall conform to the applicable parts of RFC 3280 – Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. 6

6.2.1 Cryptographic Module Standards and Controls

Any cryptographic module used by the CA, BISO, RAs, Sfollowing requirements:

o All CA D

FIPS 140-2 level 3 or otherwise deemed to provide an equivalent level of functionality and assurano All other CA cryptographic operations must be performed in a cryptographic module validated to at least

FIPS 140-1 or FIPS 140-2 Level 2 or otherwise deemed to provide an equivalent level of functionality and assurance.

o RAs Digital Signa

provide an equivalent level of functionality and assurance. Automated registration processes andother RA cryptographic operations may be performed in a software cryptographic module rated to



.

r otherwise deemed to provide an equivalent level of functionality and assurance.

Additional Re

least FIPS 140-1 or FIPS 140-2 Level 1 or otherwise deemed to provide an equivalent level of functionality and assurance, if the CA is satisfied that the physical security of the software is adequate

o All cryptomodules must automatically lock after a specific period of inactivity defined within the CPS.

o End Entities must use cryptographic modules validated to at least FIPS 140-1 or FIPS 140-2 Level 1 o

stricted Certificate Requirements:

o End Entities using restricted Certificates must use cryptographic modules validated to at least FIPS 140-2 Level 2 or otherwise deemed to provide an equivalent level of functionality and assurance.

6.2.2 Private Key Multi-Person Control

n 5.2.3 of this Certificate Policy shall protect CA digital signature Key o perform the duties associated with the role of PKS Master User, and the

S Officer or PKS Administrator must participate and

y Back-up

uirements for CA Key back-up. An Entity may back-up its own private digital signature igning Key or data protection Key. If so, the Key must be copied and stored in encrypted form and protected at a level

The CA shall backup the private data protection Keys of Subscribers created during the Certificate generation process. der all circumstances.

The CA shall implement dual physical control to access the backup media.

and expired (and revoked) CA Public Key Certificates are archived.

base is erated by the

ubscriber and are not known or stored by the CA.

Dual Authentication as described in Sectiogeneration operations. Four individuals whSecurity Officer shall participate and authorize the CA Key generation. Up to five personnel may have the authority to participate and authorize operations requiring the CA digital signature Key. All associated activities shall require Dual Authentication. The Dual Key Authentication process shall be used to protect recovery of private subscriber Keys by the BISO. Two individuals who perform the duties associated with the role of PKauthorize the Private Key recovery.

6.2.3 Private Key Escrow No Stipulation

6.2.4 Private Ke

Section 6.3.3 establishes reqsno lower than stipulated for the primary version of the Key.

The CA shall indicate in the CPS the Key back-up procedures for the CA’s Certificate(s).

The CA shall protect all transfers of non-expired and non-revoked Private Key material un

The CA shall not backup private signing Keys of the Subscribers. These Keys are only used by the Subscribers to digitally sign data.

The Private Key Backup shall abide by all security requirements established within the CPS.

6.2.5 Private Key Archival

The CA’s private signing Key Subscriber encryption Private Keys generated by the CA are backed up in the CA database. The CA dataencrypted and its integrity is protected by master Keys. Subscriber signature Private Keys are gens



o Archived CA Keys are subject to the same or greater level of security controls as Keys currently in use. e destroyed at the end of the archive period using dual control in a physically secure site.

o Archived Keys are never put back into production.

o Subscriber Private Keys archived by the CA are stored in encrypted form using a cryptographic algorithm and quirements of the CA.

If the CA provides subscriber Key archival, all archived subscriber Keys are destroyed at the end of the archive

hic module, the RA shall ensure that the Key is

ronment (SPSE). A SPSE is a secure storage area Certificates. The storage area is encrypted and protected using

ryptography. The form of storage may vary from files to tamper-resistant cryptographic tokens under the control of the

st be authenticated to the SPSE before the activation of the Private Key. The CA shall ensure that password of strong passwords to access all SPSE. The Experian Risk Management

hods for the activation of Private Keys.

All forms of cryptographic modules shall automatically deactivate the Private Key after a pre-set period of inactivity, s of the Key.

be ere stored must be over-written before the space is released

to the operating system.

Upon the termination of Certificate use, the holder of a Private Key must securely destroy all copies of that Key on all r memory, paper printouts, on hard disk, and in shared disk space.)

CA Key Archival requirements:

o All archived CA Keys ar

o Archived Keys are recovered for the shortest time period technically permissible. o Archived Keys are periodically verified to ensure that they are properly destroyed at the end of the archive

period. CA-Provided Subscriber Key Management Services requirements:

Key length based on a risk assessment and the business reo

period.

6.2.6 Private Key Transfer Into or From a Cryptographic Module Where a private signing Key is generated outside the entity’s cryptograpentered into the module in a secure manner documented in the CPS.

6.2.7 Private Key Storage on Cryptographic Module The Private Key may be stored in a Secure Personal Security Envicontaining information such as Private Keys and related cSubscriber.

6.2.8 Method of Activating Private Key

An Entity mupolicy rules are in place to require the use Committee may approve other authentication met

6.2.9 Method of Deactivating Private Key

appropriate to the risk associated with the los

When Private Keys are deactivated, they must be cleared from memory before the memory is de-allocated and mustkept in encrypted form only. Any disk space where Keys w

6.2.10 Method of Destroying Private Key

media where the Key exists (e.g. in compute

Additional information for achieving destruction requirements appears in the CPS.

6.3 Other Aspects of Key Pair Management

6.3.1 Public Key Archival



l signature verification Public Key Certificates and data protection Public Key Certificates enerated by the CA for the life of the respective Certificates.

ment..1 Key Lifetimes

Encryption CA ies

The CA shall retain all digitag

6.3.2 Certificate Maximum Operational Periods and Key Pair Usage Periods

The following table identifies the key and certificate lifetimes:

Table Error! No text of specified style in docu

End Entit

Certificate Validity Period 10 s year 3 years

Key Lifetime 10 years 2 5 months

Signat End ure CA Entities

Certificate Validity Period 10 s year 3 years

Key Lifetime 10 years 2 5 months

.3.3 CA Key Storage, Backup and Recovery

ain confidential and maintain their integrity. In particular:

irements

ic device to any other cryptographic device that meets the requirements of Section 6.2.1; d

6.3.4 Ke

er their Certificate.

ration and Installation

.

d shall be held by the CA in a secure manner prior to distribution. ialization data within twenty-four (24) hours. If the

vation Data Protection

st be protected from unauthorized use by a combination of cryptographic and s.

6

The CA shall ensure that the CA Private Keys rem

The CA private signing Key shall be held and used within a secure cryptographic device that meets the requidentified at Section 6.2.1;

o The CA private signing Key may be exported in any manner approved by the BISO from one cryptograph

o When outside the signature-creation device, the CA private signing Key shall be encrypted, anprotected by dual authorization;

son o The CA's private signing Key shall be backed up, stored and recovered under the same multi-percontrol as the original Key, such backup being securely stored at the CA backup location; and

o The CA Keys shall be stored in a dedicated Key processing hardware module and access controls shall be in place to ensure that the Keys are not accessible outside the hardware module.

y Recovery by Subscriber or Designated Certificate Holder

The CA may allow a Subscriber or Designated Certificate Holder to recov

6.4 Activation Data

6.4.1 Activation Data Gene

Any activation data must be unique and unpredictable

Keys and initialization data may be generated in bulk anUpon receipt of the initialization data, a Subscriber shall use the initSubscriber fails to use the initialization data within the twenty-four (24) hour period, they must repeat the subscription process.

6.4.2 Acti

Data used for Entity initialization muphysical access control mechanism



Keys rotected. Where passwords are used, the CA shall ensure that PKI system and/or applications enforce a

strong password policy. The level of protection must be adequate to deter a motivated attacker with substantial

er a d number of failed login attempts.

l Requirements

The CA server must include at a minimum the following security functionality:

dentities; om access memory;

ion communication and database security;

thentication of PKS roles and associated identities; nd the CA system; and

Thsoftwa

No Stipulation

Controls

The CA must use CA software designed and developed under a structured development methodology. Commercial this requirement.

g eguard design and minimize residual risk.

where SSL 128-bit or higher Certificate encryption is used and the trust path is properly verified.

The CA hardware and software shall be dedicated to performing only CA-related tasks. Any additional applications, or component software required shall be approved by the BISO.

The Secure Personal Security Environment of Entities must be protected from unauthorized use by cryptographic mechanisms.

The activation data, in conjunction with any other access control, must have an appropriate level of strength for theor data to be p

resources.

If a reusable password scheme is used, the mechanism shall include a facility to temporarily lock the account aftpredetermine

An Entity must have the capability to change its password at any time.

6.5 Computer Security Controls

6.5.1 Specific Computer Security Technica

o Access control to CA services and PKS roles; o Enforced separation of duties for PKS roles;

Identification and authentication of PKS roles and associated ioo Object reuse controls or separation for CA rando Where required, use of cryptography for sesso Archival of CA and End-Entity history and audit data; o Audit of security related events; o Automatic and regular validation of CA database integrity; o Trusted path mechanisms for the identification and auo Recovery mechanisms for Keys ao Hardening of the CA's operating system.

is functionality may be provided by the operating system, or through a combination of operating system, PKS CA re and physical safeguards.

6.5.2 Computer Security Rating

6.6 Life Cycle Security

6.6.1 System Development Controls

vendors must provided proof they meet

The design and development process must be supported by third party verification of process compliance and ongoinThreat Risk Assessments in order to influence security saf

Purchased hardware or software shall be shipped or delivered by a bonded entity in a sealed or shrink-wrapped container and be installed by trained personnel. Software may be received through electronic means

6.6.2 Security Management Controls

hardware devices, network connections



e shall be scanned for malicious code on first use and periodically afterward.

CA

Th rity of the CA database. The CA shall implement aut to control and monitor the configuration of the CA system.

for

The CA shall secure all CA operations using mechanisms such as strong authentication and encryption when the CA is

which it is connected. Such protection must include the installation of one or more devices configured to allow only the protocols and, at the option of the CA, those commands required for CA operations. Any

e

The CA shall time-stamp all issued Certificates and recorded transactions.

The CA shall indicate in the CPS (Technical Security Baselines) the policies and procedures to prevent malicious software from being loaded onto the CA equipment. CA and RA as well as automated registration softwar

The CA shall use formal configuration management methodology for the installation and ongoing maintenance of thesystem including the creation of hash values of all installed files and monthly hash verification. The CA software, when first loaded, must provide a method for the CA to verify that the software on the system:

o Originated from the software developer; o Has not been modified prior to installation; and

Is the version intended for use; o

e CA shall provide a mechanism to periodicalo ated host based mechanisms and policies

ly verify the integm

Upon installation, and at least once a week, the integrity of the CA database must be validated. The requirements this validity check shall be established within the CPS.

6.7 Network Security Controls

accessed from any network.

The CA shall ensure that security controls are put in place to provide CA integrity and availability through any open or general purpose network with

network software present must be necessary to the functioning of the CA operation.

The CA shall state in its CPS (Technical Security Baselines) such protocols and, if required, commands required for thoperation of the CA.

6.8 Time-stamping



7 CERTIFICATE, CRL, AND OCSP PROFILES

7.1 Certificate Profile

7.1.1 Version Number

The CA shall issue X.509 version 3 Certificates.

The PKI End-Entity software must support all the base (non-extension) X.509 fields:

Certificate Field Comments Version The version field for all certificates is set to v3. Serial Number A unique serial number is generated sequentially through counter

increments by the CA application for all certificates issued. Signature The signature algorithm used for all certificates is RSA with SHA-1. Issuer The issuer is set as the Distinguished Name of the CA as described in

§Error! Reference source not found. Validity The notBefore start date and the notAfter end date are specified. The

certificate validity time periods are described in §Error! Reference source not found.

Subject The subject is set as the certificate subject Distinguished Name as described in §Error! Reference source not found..

Subject Public Key Information

The subject public key contains the RSA with SHA-1 algorithm identifier and the public key.

Extensions Refer to section Error! Reference source not found. below.

7.1.2 Certificate Extensions

Rules for the inclusion, assignment of value, and processing of extensions are defined in profiles. Certificate extensions used by Certificates issued under this Certificate Policy shall conform to the applicable parts of RFC 3280 – Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Where private extensions are used, they shall be identified in its CPS.

Critical private extensions shall be interoperable in their intended community of use.

7.1.3 Algorithm Object Identifiers

The CA and End Entities shall only use algorithms approved by the Experian Risk Management Committee. The CA shall use and End Entities must support the following symmetric algorithms:

Encryption

Algorithm Comments

Triple DES The 3 independent Key option provides the best security and is therefore the preferred option.

The single Key option is not acceptable, as it reduces the security to that of a single-pass DES.

The crypto-period of any one Key should not exceed twenty-four (24) hours.



AES Shall use generalize four DES mode for 128-bit block size

CAST 5/80 or CAST 5/128

Acceptable modes of operation are the same as those originally specified for DES.

The cryptoperiod of any one Key should not exceed twenty-four hours.

The list of algorithms to be used by all PKI Entities may change without triggering the issuance of a new Certificate Policy or a change in the CP's OID.

In the event of any change in approved algorithms, the CA shall ensure that Subscribers and Designated Certificate Holders are made aware of changes in the list of algorithms approved for use within Experian. The CA shall indicate in its CPS the manner in which it will provide such notice of change.

7.1.4 Name Forms

Every DN must be in the form of an X.501 printable String.

7.1.5 Name Constraints

When used, the name constraints extension shall be populated and processed as described in RFC 3280.

7.1.6 Certificate Policy Object Identifier

The CA shall ensure that the applicable Policy OID is contained within the Certificates it issues. Experian defines the following OID structure for PKI related elements:

1.3.6.1.4.1.3101.7 All Experian PKI related 1.3.6.1.4.1.3101.7.1 CP 1.3.6.1.4.1.3101.7.1.1 Confidential Certificates 1.3.6.1.4.1.3101.7.1.2 Restricted Certificates 1.3.6.1.4.1.3101.7.2 CPS

7.1.7 Usage of Policy Constraints Extension

When used, the PolicyConstraint extension shall be populated and processed as described in RFC 3280.

7.1.8 Policy Qualifiers Syntax and Semantics

When used, the PolicyQualifiers extension shall be populated and processed as described in RFC 3280.

7.1.9 Processing Semantics for Critical Certificate Extensions

Critical extensions, when marked, shall be interpreted as defined in RFC 3280.

7.2 CRL Profile Internal CRLs and ARLs shall be published in accordance with all requirements established by this Certificate Policy. In addition to CRLs, the infrastructure shall systematically enforce revocation by denying the movement of data encrypted with revoked or expired Certificates. Additional Restricted Certificate Requirements: Experian Restricted Certificates require the implementation of an external OCSP service to automate revocation checking.



7.2.1 Version Number

The CA shall issue X.509 version two (2) CRLs and ARLs or newer versions at the discretion of the Global Security Steering Committee (GSSC). The CA shall state in its CPS the use of any extensions supported by the CA, its RAs and End Entities.

7.2.2 CRL and CRL Entry Extension

All Entity PKI software must correctly process all CRL extensions identified in RFC 3280. The CA shall state in its CPS the use of any extensions supported by the CA, its RAs and End Entities.

7.3 OCSP Profile

7.3.1 Version number(s)

For the use of OCSP servers the CA shall comply with the Experian PKI OCSP Profile with regard to version numbers.

7.3.2 OCSP Extensions.

For the use of OCSP servers is approved by the Experian Risk Management Committee, all Entity PKI software must correctly process all OCSP extensions identified in the Experian PKS OCSP Profile. The CA shall state in its CPS the use of any extensions supported by the CA, its RAs and End Entities.



any

8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS A compliance inspection determines whether the CA's performance meets the requirements established by this Certificate Policy and the CPS.

A compliance inspection of the CA will be conducted on such terms and conditions as may be established by the Experian Risk Management Committee. Compliance inspection reports shall not be made public unless required by law or judicial order.

8.1 Frequency or Circumstances of Assessment The CA will have a compliance inspection conducted at least annually.

A qualified inspector external to Experian shall conduct one (1) of every three (3) inspections of the CA. The Experian Risk Management Committee may order a compliance inspection by an agency external to the CA at any time.

The CA will certify annually to the Experian Risk Management Committee that they have at all times during the period in question complied with the requirements of this Certificate Policy and will provide reasons where it has not complied with this Certificate Policy and state any periods of non-compliance.

8.2 Identity and Qualifications of Assessor The inspector must demonstrate competence in the field of compliance inspections, and must be familiar with the requirements that the Experian Risk Management Committee imposes on the issuance and management of Certificates issued under this Certificate Policy.

8.3 Assessor's Relationship to Assessed Entity An inspector must be independent of the management or operation of the CA.

An inspector who is external to Experian must be independent of the CA and meet the same ethical obligations for independence applicable to accounting auditors.

8.4 Topics covered by Assessment At a minimum, the scope of a compliance inspection will include whether:

o The CPS provides, in sufficient detail, the technical, procedural and personnel practices of the CA required under this Certificate Policy;

o The CA implements and complies with those technical, procedural and personnel practices; and o The Repository Manager, RAs and Designated Certificate Holders implement and comply with the

technical, procedural and personnel practices set out by the CA.

An inspector may consult with Business Unit management to determine relevant applications, procedures and practices, which may have a bearing on the inspection.

The Experian Risk Management Committee may increase the scope of a compliance inspection on such terms as it deems appropriate.

8.5 Actions Taken as a Result of Deficiency The inspection results will be submitted to the accreditation authority of the CA and the Experian Risk Management Committee. If irregularities are found, the CA will submit a report to the Experian Risk Management Committee as toaction the CA will take in response to the inspection report.



Where a CA fails to take appropriate action in response to the inspection report, the accreditation authority may:

1. Indicate the irregularities, but allow the CA to continue operations until the next programmed inspection;

2. Allow the CA to continue operations for a maximum of thirty (30) days pending correction of any problem prior to revocation;

3. Revoke the CA's Certificate.

Any decision regarding which of these actions to take will be based on the severity of the irregularities.

8.6 Communication of Assessment Results Inspection information is to be classified as Experian Restricted and must not be disclosed for any purpose other than inspection purposes or where required by agreement or by law pursuant to judicial authorization or an express statutory requirement.



9 OTHER BUSINESS MATTERS

9.1 Fees The charging of fees or cost allocation in relation with the enrollment in, or the use of PKS from a CA is outside the scope of this Certificate Policy. Such fees are determined and implemented by Experian management. 9.2 Financial Responsibility Financial responsibility in connection with PKS shall be determined by Experian management. 9.3 Confidentiality of Business Information Information shall be defined as Confidential or Restricted in accordance with Experian’s Information Security Policy as follows:



9.4 Privacy of Personal Information

The CA shall ensure that any application for a Certificate to be issued by the CA contains language that obtains the consent of the applicant for the use and disclosure of private information as outlined in this Certificate Policy and in any agreement. This consent shall clearly convey that the use of a Certificate issued by an Experian CA does not invoke an expectation of privacy. The collection, use, dissemination and processing of personal information contained in the PKS system by all participants shall be in accordance with applicable law and relevant Experian policies applicable to personal private information. This CP only applies to private information contained in the PKS system.

9.4.1 Sensitivity of Types of Private Information Private information is (i) identifiable information about an individual and (ii) business confidential information from an organization. The sensitivity of private information held by departments - in connection with Certificates issued under this Certificate Policy - varies and is determined by reference to applicable international, federal, state and local government statutes and regulations. Certificate revocation/suspension information, including reason codes, may be included in a CRL entry. Certificates and CRLs are not considered private information for the purposes of this Certificate Policy.

9.4.2 Permitted Collection of Private Information

The CA shall not collect private information for any purpose other than the issuance and management of Certificates to personnel of a Business Unit, the CA or any CA service provider, RA or End-Entity. The CA shall not collect any more information than is necessary for that purpose.

Business Units may require additional information, proof of credentials or authorization for enrollment with a specific CA.

9.4.3 Permitted Use of Private Information



The CA shall only use private information collected by the CA or RA for the purpose of issuing and managing a Certificate under this Certificate Policy.

9.4.4 Permitted Distribution of Personal Information

Subject to Sections 2.5.6 and 2.5.7, and the limitations and restrictions imposed by applicable law, the CA and any RA may distribute private information only to personnel of departments or agencies that require such information to assist in the issuance and management of Certificates. The CA or any RA may release private information if required by applicable law. All disclosures under this Section 9.4.4 shall be coordinated through the Experian Risk Management Committee.

Any release of Experian specific restricted or confidential information is governed by applicable policies. Any questions concerning the collection, use, processing, and sharing of restricted or confidential information, including personal private information within the PKS system should be addressed to the Experian Information Security Office.

9.4.5 Opportunity of Owner to Correct Private Information

The owner of private information held within the PKS system shall have the opportunity to correct any inaccuracies or request any corrections in the private information provided by the owner. The CA and any RA will designate an individual to be responsible to receive any requests to correct PKI-related private information.

Business units or departments that handle private information in connection with services for which Certificates have been issued under this Certificate Policy shall comply with applicable law and Experian policies. Opportunities to correct such information will be determined by the Business Unit Manager.

9.5 Intellectual Property Rights All right, title and interest in all intellectual property rights in or associated with this Certificate Policy, CRLs, ARLs, Distinguished Names, Service Arrangements, CA Public Keys and Certificates as well as End Entity Certificates (the "Materials"), including all modifications and enhancements thereof, are and shall remain the exclusive property of Experian.

Subscribers and Relying Parties may use the Materials only for the purposes of complying with this Certificate Policy. Any other personal or commercial use is strictly prohibited. This Certificate Policy may be copied and distributed, provided all copyright or other proprietary notices, if included, are retained or an equivalent acknowledgment is provided as to its origin and ownership.

Any software provided in conjunction with the use of the Materials is the property of Experian or its third party licensors. The use of any such software shall be in accordance with the terms of the license applicable to the software.

9.6 Participant Obligations

9.6.1 CA Obligations The CA is responsible for creation and signing of Certificates binding Subscribers, Designated Certificate holders and BISO and other CAs with their public verification Keys; and promulgating Certificate status through CRLs and ARLs. End-Entity Digital Signature Key pairs may be generated using automated registration processes. The CA may generate End-Entity Confidentiality Key pairs. The CA shall:

1. Operate for the purpose of issuing and managing Certificates for Subscribers, Designated Certificate Holders, BISO, RAs and Repository Managers, as required, and issuing and managing cross-Certificates in accordance with this Certificate Policy, the applicable CPS, applicable laws, and to comply with all policies;



2. Prepare a detailed CPS describing all practices, procedures and requirements required to comply with this Certificate Policy;

3. Ensure that all RAs and Repository Managers acting on its behalf operate in accordance with this Certificate Policy and the applicable CPS;

4. Ensure that appropriate agreements or arrangements outlining the respective rights, privileges and obligations of the parties are entered into with:

a. Subscribers for Certificates issued to them or on their direction; and

b. All others who are performing functions on behalf of the CA.

5. Provide, in a publicly available document, such information as applicants for Certificates may require to request the issuance of a Certificate, its suspension or revocation;

6. Endeavor to provide Subscribers, Designated Certificate Holders, , and Relying Parties with notice of their respective rights, privileges and obligations pertaining to their use of any PKI Keys, Certificates, hardware or software provided by the CA;

7. Notify a Subscriber, a Client Responsible Individual or Designated Certificate Holder, as the case may be, when a Certificate for their use is:

a. Issued;

b. Suspended; or

c. Revoked.

8. Ensure that the period for which the Entity has to complete its initialization process is no longer than 21 calendar days;

9. Provide notice in Certificates issued under this Certificate Policy of the address of the CRL;

10. Provide appropriate notice to all interested parties as to the CA's procedures concerning the expiration, suspension, revocation and renewal of Certificates;

11. Make revocation information available to a Subscriber, Designated Certificate Holder or Relying Party as required under this Certificate Policy;

12. Use its private signing Key only to sign Certificates and CRLs and for no other purpose;

13. Institute procedures to ensure BISO associated with PKI roles (e.g. PKI Master User; PKI Officers, and PKI Administrators) are accountable for actions they perform and ensure evidence is available to link any action to the person performing such action;

14. Ensure that BISO use Private Keys issued only for the purpose of conducting CA duties;

15. Subject to applicable laws and policies of the local government where the CA is hosted, ensure that the information held by the CA or on behalf of the CA comply with such local laws;

16. Except as otherwise provided, publication of a Certificate in a repository constitutes the CA's certification, and notice to a Subscriber or a Relying Party who may access the Certificate in the repository, that the information stated in the Certificate was verified in accordance with this Certificate Policy.

17. Ensure that it implements mechanisms to minimize the amount of time the CA services are unavailable to End Entities; and

18. Embed a notice of limitations of any liability within the Certificates it creates consistent with this Certificate Policy.



A Relying Party shall:

When required as a result of the technology used (e.g. roaming profiles), the CA shall place Subscriber or Designated Certificate Holder private signature Keys in protected Storage.

9.6.2 RA Obligations

The RA shall:

1. Comply with applicable provisions of this Certificate Policy and CPS, and with the terms and conditions of any agreement or arrangement with the CA;

2. Inform applicants of the application process, including the process for the initialization of Certificates;

3. Identify and authenticate the identities of applicants seeking to become Subscribers or designated Certificate Holders and, when submitting application information to the CA, certify to the CA that it has done so in accordance with the requirements of this Certificate Policy;

4. Inform Subscribers, or Designated Certificate Holders, as the case may be, of (i) their respective rights, privileges and obligations pertaining to their use of any PKI Keys, Certificates, hardware or software provided by the CA; and (ii) the CA's procedures for the expiration, suspension, revocation and renewal of Keys and Certificates;

5. Where the CA does not record the information, ensure, for audit purposes, that records of actions carried out in performance of RA duties are maintained; and

6. Protect the RA's Private Keys as directed by the CA.

RAs may support both automated on-line and off-line registration processes.

9.6.3 Subscriber or Designated Certificate Holder Obligations

A Subscriber or Designated Certificate Holder shall:

1. Ensure that information submitted to the CA or RA directly or on their behalf is complete and accurate;

2. Comply with the terms of the applicable Subscriber Agreement or other binding instrument satisfactory to the CA;

3. Use or rely on Keys or Certificates only for purposes permitted by this Certificate Policy and for no other purpose;

4. Perform intended cryptographic operations using appropriate software and hardware;

5. Protect their Private Keys, passwords and Key tokens (if applicable) in accordance with this Certificate Policy or as directed by the CA, and take all reasonable measures to prevent their loss, disclosure, modification or unauthorized use;

6. Assume responsibility for the protection of any information following its decryption and/or verification, especially where the Subscriber or Designated Certificate Holder chooses to re-encrypt information for storage purposes;

7. Within five (5) minutes notify the CA in such manner as specified by the CA in the event of the compromise or suspected compromise of a Subscriber's or Designated Certificate Holder's Private Keys, password or Key tokens (if applicable); and

8. With respect to the use outside of the local government of hardware or software containing cryptographic products or elements, verify that the importation and/or use of such products is permitted within a particular country or jurisdiction.

9.6.4 Relying Party Obligations



ed cryptographic operations using appropriate software and hardware;

ertificate against the appropriate and current CRL or the OCSP server of a Certificate Status Authority in accordance with the requirements stated in Sections 4.9.10 or 4.10.2 as

ertificate validation using a CRL, validate the digital signature of the CA affixed to the CRL.

9.6.5 Repo s

erwise acts as a repository manager, the CA shall:

ted Certificate Holders of the location of any CRL or OCSP server;

information available within the timeframes specified in this Certificate Policy; and

ISO can write or modify the on-line version of the CP.

access controls with respect to Certificates, CRLs or on-line Certificate status checking.

ss Manager Obligations

he Business Information Security Office (BISO) shall ensure there is a clear separation of duty between system system users.

ve

cal law requirements;

ance with government security requirements, where

d

een completed;

s taken steps to ensure that users of the service will be given effective notice of any such limitations.

1. Perform intend

2. Prior to relying on a Certificate:

a. Check the status of the C

applicable; and

b. With respect to C

sitory Manager Obligation

Where the CA operates a repository or oth

1. Publish Certificates and CRLs;

2. Inform Subscribers and Designa

3. Publish the status of Certificates through Certificate revocation lists, OCSP servers, or otherwise make

4. Configure operating system and repository access controls so that only authorized B

The CA should mandate repository

9.6.6 Busine

Tadministration, oversight activities (e.g. audits) and

The CA shall issue Certificates for Programs where the BISO has certified to the CA that appropriate measures habeen taken to ensure that:

1. The integrity of the PKS application is maintained throughout its lifecycle;

2. The Program software is developed using a structured design methodology;

3. Fail secure mechanisms are implemented in applications;

4. Program Applications:

a. Satisfy applicable lo

b. Have been certified and accredited in accordrequired;

c. Advise PKS users of security vulnerabilities and fixes for any software used to access the PKS; an

d. Provide explicit notice of the completion of a signing operation.

5. A Threat and Risk Assessment (TRA) that complies with Experian Security Policy has b

6. The BISO has assessed and considered issues of potential liability arising out of the provision of PKS on-line and the advisability of establishing processes, procedures and conditions to mitigate liability risks, and ha



Additional Requirements for Restricted Certificates: The CA shall issue restricted Certificates only for use by Business Units where the BISO establishes to its satisfaction that the client environment in which the Subscriber or Designated Certificate Holder uses a Limited Purpose Certificate has security mechanisms in place to ensure it is a controlled environment.

9.7 Disclaimers of Warranties EXPERIAN DISCLAIMS ANY AND ALL REPRESENTATIONS AND WARRANTIES OF ANY TYPE WITH RESPECT TO ANY CERTIFICATE ON WHICH A PARTY MAY RELY, WHETHER EXPRESS OR IMPLIED, INCLUDING

OF MERCHANTABILITY, FITNESS FOR A PARTICULAR RINGEMENT.

ARISING FROM THE ISSUANCE OR USE OF F PKS, WHETHER IN CONTRACT OR IN TORT, EVEN IF EXPERIAN HAS BEEN F SUCH DAMAGES.

be their

ommunications with participants

on requirements established within this policy the CA shall digitally sign e-mail notices, followed by a signed -mail acknowledgement of receipt. Notices posted on website shall also contain a digital signature to enhance the

ll amendments to this Certificate Policy shall be made with the consultation of the Risk Management Committee. All this Certificate Policy.

tion Procedures

WITHOUT LIMITATION ANY IMPLIED WARRANTY PURPOSE, TITLE, RELIABILITY, AND INF 9.8 Exclusion of Liability ACCEPTANCE, RELIANCE AND USE OF ANY CERTIFICATE SHALL BE AT THE PARTY’S OWN RISK, AND UNDER NO CIRCUMSTANCES SHALL EXPERIAN OR ANY CA BE LIABLE FOR ANY DIRECT, INDIRECT,

ONSEQUENTIAL, SPECIAL OR INCIDENTAL DAMAGESCCERTIFICATES OR PROVISION OADVISED OF THE POSSIBILITY O

Nothing in this Certificate Policy creates, alters or eliminates any other obligation, responsibility, or liability that mayimposed on or assumed by a department or Business Unit that makes use of the services provided by the CA forrespective Business Units. The responsibility to establish any liability limits of Experian in connection with a Business Unit remains with the responsible BISO.

The rights, privileges and obligations, including limitations on liability, of a Relying Party who is a Subscriber of another CA may be addressed in an agreement between that Subscriber and such CA.

9.10 Term and Termination This Certificate Policy shall remain in effect until rescinded or expressly replaced by the Experian Risk Management Committee. 9.11 Individual notices and c Periodically the CA may communicate with users about changes or scheduled maintenance. When fulfilling communicatiesecurity integrity of the message. All electronic e-mail related to CA business shall use digital signatures. 9.12 Amendments APKS participants shall be notified of any amendments in accordance with 9.13 Dispute ResoluA dispute related to Key and Certificate management between departments should be resolved by customary management processes. A dispute not settled by negotiation shall be resolved by the Experian Chief Information

ecurity Officer. S 9.14 Governing Law



uction,

Applicable Law

require the approval of appropriate government authorities. Anyone

tire discretion, enter into cross-certification agreements or arrangements with external (e.g. non-xperian) CAs or recognize Certificates issued by an external CA. Such agreements or arrangements may not

is Certificate Policy. However, the fact that their respective Certificate s Certificate Policy would not, by itself, preclude cross-certification between

rities. This determination shall be made jointly by such parties.

o an

notice on the CA's web site.

agreements or arrangements made with other CAs.

s-certification with another CA, and only upon terms and conditions approved by the Risk Management Committee, the CA may recognize or otherwise rely upon Certificates issued by a CA external to the PKS

the Experian CA.

The laws of the State of California, exclusive of its conflicts-of-laws principles, govern the enforceability, constrinterpretation and validity of this Certificate Policy. 9.15 Compliance with Participants shall comply with the applicable statues and laws of the country where the CA operates in or as otherwiseagreed in separate agreements. All requirements related to cryptographic hardware and software export control laws shall appear in the CPS. The export or import of software used by the CA may using the services provided by the CA shall comply with applicable export and import laws and regulations. The CA shall not be responsible for obtaining any necessary permission to export or import software or notifying users as to their existence or content. 9.16 Miscellaneous Provisions

9.16.1 Cross-certification and Recognition

Experian may, at its enEnecessarily include all of the provisions in thPolicies are not identical to each other or thiExperian and non-Experian Certification Autho

9.16.2 Cross-certification

The Risk Management Committee will identify all procedures and requirements that the CA will follow with respect tapplication for a cross-Certificate in its cross-certification procedures. Notice of the existence of any cross-certification or recognition of Certificates will be provided to Subscribers and Designated Certificate Holders by publication of a

The CA shall document any

9.16.3 Recognition of Other CAs

In the absence of cros

to authenticate Subscribers of that CA or to authenticate potential Subscribers of

9.17 Other Provisions Not stipulated

Experian Information Securitypks.experian.com/experian_certificate_policy_20090624.pdf · Experian...

Documents

Transcript of Experian Information Securitypks.experian.com/experian_certificate_policy_20090624.pdf · Experian...