THE RSA ROOT SIGNING SERVICE Certification Practice Statement For RSA Certificate Authorities (CAs) Published By: RSA Security Inc.

(1)

THE RSA ROOT SIGNING SERVICE

Certification Practice Statement

For RSA Certificate Authorities (CAs)

Last Revision Date:

June 28, 2007

Version: 3.0

(2)

RSA Security Inc.

THIS DOCUMENT IS CONFIDENTIAL AND MAY NOT BE DISTRIBUTED UNLESS AUTHORIZED BY RSA Security Inc.

BSAFE, RSA, SecurCare and SecurID are registered trademarks, and RSA Security Inc., Confidence Inspired and the RSA logo are trademarks of RSA Security Inc.

All other trademarks mentioned herein are the property of their respective owners.

(3)

Revision History

Version Date Author’s initials Description of changes 0.01 2001/7/24 MS Initial release.

0.02 2001/7/26 MS Incremental changes.

0.03 2001/7/27 MS Added architecture.

0.04 2001/7/31 MS Added logical diagram.

0.05 2001/8/07 MS Physical controls, termination, disaster recovery (severity), compliance review, application.

0.06 2001/8/8 MS Name claim dispute resolution

0.07 2001/8/14 MS Marketing content in Part A, changed to the RSA ROOT SIGNING SERVICE CPS for issuing certificates to CAs only.

0.08 2001/8/15 MS, TS Added Tom Strickland’s section 2.7, 4.5 and 4.6, adjusted section 3.1.6,-3.1.8.

0.09 2001/9/6 MS Created CPS for online root (CPS2) Removed and limited sections dealing with end entities, RAs and subCAs.

0.1 2001/9/13 MS Clean up of terms, adjustments to Compliance Review to make it easier for customers, clean up of “must” to “will” in sections.

0.2 2001/10/2 MS Change name from RSA CA to RSA PUBLIC

ROOT CA V1. Add changes from Andrew Nash. Add tier diagram to overview section.

0.3 2001/10/15 MS Changes to CPS to reflect new direction – chaining service offering only.

0.4 2001/11/16 MS Incorporate comments from Beth MacMonigle, revised section 4.5 to more clearly define audit logs collected.

0.5 2001/12/06 DF Minor revision to clarify Service provider requirements.

0.6 2001/12/07 MS Minor revisions in section 7 to clarify key bit assertions for path length and basic

constraints.

0.7 2002/2/7 MS Major revisions to include CA Operations processes, RSA Administration Processes, Customer Processes and updated EDS facility procedures and policies.

0.8 2002/2/28 MS Added “the” to the front of RSA ROOT SIGNING SERVICE where appropriate.

1.0 2002/2/28 DF Promoted to final version from draft.

1.1 2002/3/31 MS Modifications to CPS to conform to Web Trust requirements.

1.2 2002/8/26 DF Change to section 4.9 regarding CA termination and changed company name to RSA Inc.

1.3 2005/11/27 DF Update in preparation for conversion to 3647 Removed Keon brand reference. Incorporated the operation of the RSA 2048 v3 root.

2.0 12/14/2005 DF Converted to RFC3647 format/

(4)

RSA Security Inc. iv 6/28/2007

O

VERVIEW

This Certification Practice Statement (CPS) defines the practices and procedures for the RSA ROOT SIGNING SERVICE in signing and issuing certificates to Participating CAs. This CPS is in conformance with the RSA ROOT SIGNING SERVICE Certificate Policy.

This document describes how the Certificate Authorities (CAs) in the RSA ROOT SIGNING SERVICE, the RSA CAs, operate. This includes:

• RSA Root CA (1024v1), known as the ValiCert Class 3 Policy Validation Authority; • RSA PUBLIC ROOT CA V1;

• RSA PUBLIC ROOT CA V2; and, • RSA Root CA (2048v3).

This document describes the relationships between the RSA Root CAs, the RSA PUBLIC ROOT CA V1 and Participating CAs but does not define how Participating CAs, and their associated RAs and end entities operate. Participating CAs is a term used to describe a CA chained to one of the RSA CAs.

The RSA ROOT SIGNING SERVICE CPS generally conforms generally conforms to the IETF PKIX Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practice Statement Framework (also known as RFC 3647).

This document is divided into eight sections:

• Section 1 - Provides an overview of the policy and set of provisions, as well as the types of entities and the appropriate applications for certificates.

• Section 2 - Contains any applicable provisions regarding identification of the entity or entities that operate repositories; responsibility of a PKI participant to publish information regarding its practices, certificates, and the current status; frequency of publication; and access control on published information.

• Section 3 - Covers the identification and authentication requirements for certificate related activity.

• Section 4 - Deals with certificate life-cycle management and operational requirements including application for a certificate, revocation, suspension, audit, archival and compromise.

• Section 5 - Covers facility, management and operational controls (physical and procedural security requirements).

• Section 6 - Provides the technical controls with regard to cryptographic key requirements.

• Section 7 - Defines requirements for certificate, Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) formats. This includes information on profiles, versions, and extensions used.

• Section 8 - Addresses topics covered and methodology used for assessments/audits; frequency of compliance audits or assessments; identity and/or qualifications of the personnel performing the audit or assessment; actions taken as a result of deficiencies found during the assessment; and who is entitled to see results of an assessment. • Section 9 - Covers general business and legal matters: the business issues of fees,

(11)

THE RSA ROOT SIGNING SERVICE Public Key Infrastructure Hierarchy

The RSA Root CA (1024v1 - Valicert CA) and the RSA Public Root CA v1 operate in an off-line mode. The RSA Public Root CA v1 was implemented as an intermediate X.509 version 3 CA to the root and is used to sign Participating CAs. This allows the RSA ROOT SIGNING SERVICE to provide version 3 functionality to Participating CAs. Also, in compromise situations with the RSA Public Root CA v1, the RSA Root CA would be used to revoke the RSA Public Root CA v1 certificate and resign a new working CA to replace the RSA Public Root CA.

The RSA Public Root CA v2 operates in an offline mode and has been implemented to sign Participating CAs, including Participating CAs that will issue Extended Validation certificates. The RSA Public Root CA v2 also has a trust relationship established with the RSA Root CA to provide ubiquity to users of earlier application releases.

The RSA Root CA (2048v3) also operates in an offline mode, and is used to sign Participating CAs. As it is a X.509 version 3 CA, it was determined that no intermediate CA would be required in its hierarchy.

All RSA CAs operating as part of the RSA ROOT SIGNING SERVICE must conform to the RSA ROOT SIGNING SERVICE Certificate Policy.

All Participating CAs must have an associated CPS, and must conform to the RSA ROOT SIGNING SERVICE Certificate Policy.

This CPS is applicable to the RSA CAs, but does not apply to the Participating CAs.

In cases where there are differences in procedures based on CA, the section will specify which CA is being addressed. Otherwise the section applies to the RSA CAs.

RSA with this CPS document and the accompanying CP addresses the requirements as set forth by the CA/Browser Forum Guidelines for Extended Validation Certificates

(12)

CPS

S

PECIFICATION

1 INTRODUCTION

1.1 Overview

The RSA ROOT SIGNING SERVICE Certificate Policy (CP) describes the legal, business and technical requirements for the RSA CAs. The Certification Practice Statement (CPS) describes how these requirements are met in issuing certificates to CAs that are to be chained to the RSA ROOT SIGNING SERVICE.

This CPS does not provide details on the operation of the RSA CAs; rather it provides an overview of the practices. Details of the operations are found in supporting documents.

1.2 Document name and identification

This document is titled the RSA ROOT SIGNING SERVICE Certification Practice Statement for RSA Certificate Authorities or “RSA ROOT SIGNING SERVICE CPS”

The alphanumeric OID for the Certificate Policy is RSAChainingCP2.

The object identifier (OID) used for certificates (except for EV certificates) issued under this CPS is: 1.2.840.113549.5.6.1; the OID for EV SSL certificates issued under this CPS is

1.2.840.113549.5.6.2.

1.3 PKI

participants

The RSA CAs are operated as a Root CAs with certificates that have a high ubiquity on the Internet. High ubiquity in the context of certificates means that the Root CA certificate appears in most browsers as a Trusted Root Certificate Authority. The Trusted CA is the RSA Root CA (1024v1), with the friendly name ValiCert Class 3 Policy Validation Authority, or the RSA Root CA (2048v3) with the friendly name RSA Security 2048 v3. High ubiquity is good for applications such as e-mail and secure web services where interaction with many external organizations and links to a known and trusted root CA certificate is essential.

Additional Root CAs may be added to the RSA ROOT SIGNING SERVICE as business requires. The RSA CAs will sign and issue certificates to Participating CAs.

1.3.1 Certification authorities

The RSA Root CAs (1024v1 – Valicert) operates under the RSA ROOT SIGNING SERVICE CP and has signed the RSA PUBLIC ROOT CA V1 certificate to bind the RSA PUBLIC ROOT CA V1 to the private key of the RSA Root CA.

The RSA PUBLIC ROOT CA V1 operating under the RSA ROOT SIGNING SERVICE CP will sign certificates that bind Participating CAs to the private key of the RSA PUBLIC ROOT CA V1. The RSA PUBLIC ROOT CA V2 operating under the RSA ROOT SIGNING SERVICE CP will sign certificates that bind Participating CAs to the private key of the RSA PUBLIC ROOT CA V2. The RSA Root CA (2048 v3) operates under the RSA ROOT SIGNING SERVICE CP will sign certificates that bind Participating CAs to the private key of the RSA Root CA (2048 v3).

(13)

1.3.2 Registration authorities

There are no Registration Authorities associated with the RSA CAs. All identification and authentication requirements are performed at contract time for any RSA CA that signs a

Participating CA. No identification and authentication requirements are required for the RSA Root CA (1024 v1).

1.3.3 Subscribers

For the purposes of this CPS a Subscriber is a Participating CA and is bound by all terms and conditions in the CP, the RSA Root Signing Agreement and applicable Statements of Work (SOW).

Eligibility for a certificate is at the sole discretion of the RSA ROOT SIGNING SERVICE. The RSA CAs may administer any number of subscribers.

1.3.4 Relying parties

A Relying Party is an entity that relies on a certificate or information about the certificate that is issued by the RSA CAs.

1.3.5 Other participants No stipulation.

1.4 Certificate

usage

This CPS is applicable to all certificates issued by the RSA CAs. The practices described in this CPS apply to the issuance, use of the certificates and the revocation of certificates of

Participating CAs under the one of the RSA Root CAs. There may be a limitation on the chaining length of the Participating CA such that the CA cannot create additional sub-CAs unless

otherwise described in the RSA Root Signing Agreement. Any limitation of chaining length will be described in contractual obligations not in technical limitations.

1.4.1 Appropriate certificate uses

The RSA CAs will issue certificates to participating CAs which will in-turn allow these participating CAs to issue certificates for one or more of the following uses:

(14)

RSA Security Inc. Page 5 6/28/2007 1.4.2 Prohibited certificate uses

Certificates issued under this CPS by one of the RSA CAs are prohibited from any other use not specified in Section 1.4.1.

In the case that Participating CAs will issue EV SSL certificates, the issuing CA must not issue EV Certificates to any person or any organization or entity that does not satisfy the requirements as specified by the CA/Browser Forum Guidelines.

1.5 Policy

administration

RSA ROOT SIGNING SERVICE Policy Management Authority is the overall administrative authority of this CPS.

1.5.1 Organization administering the document

RSA ROOT SIGNING SERVICE Policy Management Authority is the responsible authority for reviewing and approving changes to the RSA ROOT SIGNING SERVICE CPS. Written and signed comments on proposed changes shall be directed to the RSA ROOT SIGNING SERVICE contact as described in Section 1.5.2. Decisions with respect to the proposed changes are at the sole discretion of the RSA ROOT SIGNING SERVICE Policy Management Authority.

1.5.2 Contact person

The following is the primary contact for the RSA ROOT SIGNING Service:

RSA ROOT SIGNING SERVICE Manager [email protected]

RSA, The Security Division of EMC2 174 Middlesex Turnpike

Bedford, MA 01730

Telephone: (781) 515-5000

1.5.3 Person determining CPS suitability for the policy

RSA ROOT SIGNING SERVICE Policy Management Authority is the administrative entity for determining a CPS’s suitability to RSA ROOT SIGNING SERVICE CP.

1.5.4 CPS approval procedures

The RSA ROOT SIGNING SERVICE Policy Management Authority will review any modifications, additions or deletions to this CPS, and determine if modifications, additions or deletions are acceptable and do not jeopardize operations or the security of the RSA ROOT SIGNING SERVICE.

1.6 Definitions and acronyms

(15)

2 PUBLICATION

AND

REPOSITORY

RESPONSIBILITIES

2.1 Repositories

The RSA CAs will provide a certificate and a CRL file that is located in the RSA Repository; the availability of the repositories will be defined in the RSA Root Signing Agreement and this CPS. For EV Certificate status checking, the CA will maintain an online 24/7 Repository mechanism whereby clients can automatically check online the current status of all CA certificates.

2.2 Publication of certification information

Subscribers shall be notified that a CA may publish information submitted by them to publicly accessible directories in association with certificate status information. The publication of this information will be within the limits of section 9.3 and 9.4. Certificate and CRL publication shall be in accordance with Section 4.

RSA ROOT SIGNING SERVICE retains an online repository of documents where it makes certain disclosure about its practices, procedures and the content of certain of its policies including this CPS. RSA ROOT SIGNING SERVICE reserves the right to make available and publish information on its policies by any means it sees fit. Due to their sensitivity, RSA ROOT SIGNING SERVICE may refrain from making publicly available certain subcomponents and elements of such documents including certain security controls and procedures related with the CA functions.

RSA ROOT SIGNING SERVICE shall provide full text version of this CPS and RSA ROOT SIGNING SERVICE CP when necessary for the purposes of audit, accreditation or as required by law.

2.3 Time or frequency of publication

Certificate information shall be distributed and/or published promptly upon issuance. Maximum time limits and frequency of certificate and CRL publishing are described in section 4 of this CPS. Updates to this CPS are published in accordance with section 9.12.

2.4 Access controls on repositories

RSA ROOT SIGNING SERVICE keeps access to its public repository available to Relying Parties with the purpose of validating certificates it issued. RSA ROOT SIGNING SERVICE may limit or restrict access to its services such as the publication of status information on third party

databases, private directories, etc.

Access controls may be instituted at the discretion of the RSA ROOT SIGNING SERVICE with respect to online certificate status. Certificates will be published promptly upon issuance. The RSA CAs will:

1. Provide directly or with agreement with a repository, unrestricted access to certificates and CRLs. CRL publication will be in accordance with Section 4.

2. Include within any certificate it issues the URL of the website maintained by, or on behalf of, the CA,

3. Provide the publication of its CP on a web site maintained by, or on behalf of the CA, the location of which will be indicated in compliance with Section 8.

(16)

(17)

3 IDENTIFICATION

AND

AUTHENTICATION

A Subscriber (Participating CA) of the RSA ROOT SIGNING SERVICE is an entity issued a certificate signed by one of the RSA CAs. The Subscriber is represented by an employee of the Participating CA specifically authorized to request a certificate in the RSA Root Signing

agreement.

3.1 Naming

3.1.1 Types of names

Each entity will have a clearly distinguishable and unique X.501 Distinguished Name (DN) in the certificate subject name field and in accordance with PKIX Part 1. Each entity may use an alternative name via the SubjectAlternateName field, which also will be in accordance with PKIX Part 1. The DN will be in the form of a X.501 printableString and will not be blank.

For Participating CAs that will issue EV certificates the CA’s certificate Subject field should conform to PKIX standard with an ASN.1 OID of 2.5.4.10, and the field must be the full legal incorporated name. In addition an assumed name or d/b/a name may be used in the Subject field provided the full legal name follows in parenthesis. In such cases the string of characters cannot exceed 64 bytes, as defined by RFC 3280; otherwise only the full legal name shall be used.

3.1.2 Need for names to be meaningful

The contents of each certificate Subject and Issuer name field will have an association with the authenticated name of the entity. The relative distinguished name (RDN) should reflect the authenticated legal name of the entity or in cases where the identity of the subscriber is protected the name could be a combination of alphanumeric characters.

In cases regarding the issuance of EV certificates, Distinguished Names will be the full legal name used for incorporation, or an assumed name or d/b/a (doing business as).

3.1.3 Anonymity or pseudonymity of subscribers

No stipulation; at the discretion of the RSA ROOT SIGNING SERVICE. 3.1.4 Rules for interpreting various name forms

No stipulation; at the discretion of the RSA ROOT SIGNING SERVICE. 3.1.5 Uniqueness of names

Distinguished names will be unique for all Participating CAs.

For participating CAs that will issue EV SSL certificates; Distinguished Names (DNs) will be unique within their domain, and not ambiguous.

3.1.6 Recognition, authentication, and role of trademarks

(18)

RSA Security Inc. Page 9 6/28/2007 The RSA CAs reserve the right to make all decisions regarding names in all assigned certificates. A party requesting a certificate must demonstrate its right to use a particular name.

If a party wishes to dispute the name contained in an existing certificate they must present evidence that they are the owner of that name.

In the case of an organization, incorporation papers or legal representation that clearly demonstrates the use of that name must be presented. In the event that the name is used by more than one organization (i.e. the same name is used in different states), the RSA CAs will add the appropriate characters to the new name to distinguish it from the other name.

3.2 Initial Indentity validation

3.2.1 Method to prove possession of private key

The method to prove possession of a private key shall be PKCS #10, or another cryptographically equivalent request (digitally signed request with private key).

3.2.2 Authentication of organization identity

An application to be a CA will be made by a person or organization authorized to act on behalf of the prospective CA. The organization applying for a CA certificate will have verified the identity of the individual authorized to act on behalf of the organization. The organization should keep a record of the type and details of identification used.

For participating CAs that will issue EV SSL certificates, RSA will authenticate the organizational identity in accordance with the CA/Browser Forum Guidelines for Extended Validation

Certificates. RSA will authenticate the applicant’s: • Legal Existence

• Identity

• Organization Name

• Assumed Name (Optional, only if used by Applicant) • Right to use the Domain Name

(19)

3.2.3 Authentication of individual identity

Individuals authorized to act on behalf of a Subscriber (Participating CA) will be properly identified as a Technical Point of Contact in the RSA Root Signing Agreement or an addendum. The individual’s name, title, phone number, e-mail address, and location details must be provided. RSA will authenticate the identity of a Technical Point of Contact and verify their employment status with the Subscriber organization. RSA will authenticate the Technical Point of Contact’s Legal Existence by validating the following:

1. The Technical Point of Contact is a natural person whose name matches the Technical Point of Contact’s name in the RSA Root Signing Agreement

2. A current signed government issued identification document that includes a photo of the Individual such as:

• A passport • A driver’s license • Military ID

3. A legal opinion confirming their identity and their authority to act on behalf of a Subscriber.

3.2.3.1 Individual (Person) Certificate Applicant No stipulation.

3.2.3.2 Application Server Certificate Applicant

The RSA CAs will not issue certificates to devices or applications, except in the extraordinary circumstance where a certificate may be required for test purposes. Any such certificate shall be approved by the RSA ROOT SIGNING SERVICE Manager.

3.2.3.3 CA Administrator and Vettor Applicant

A request to acquire a CA administrator or vettor certificate will be made only by designated CA personnel. The request will require access to the CA administrative request URL (Secure SSL connection), which requires a unique identifier provided by an existing CA Administrator. The request will be manually vetted and approved by existing administrators, requiring two administrators to access this function(s).

3.2.4 Non-verified subscriber information No stipulation.

3.2.5 Validation of authority

Through the information provided as part of the RSA Root Signing Agreement, the identity of the individual making the application, the validity of that individual, department and/or organization to make a certificate application, and their authority to receive the certificate(s) for that organization is validated.

3.2.6 Criteria for interoperation

(20)

3.3 Identification and authentication for re-key requests

3.3.1 Identification and authentication for routine re-key

Re-key requires the replacement of a public key. A new public/private key pair is generated and a new certificate is issued.

Re-key is not supported by the RSA ROOT SIGNING SERVICE.

3.3.2 Identification and authentication for re-key after revocation Re-key is not supported by the RSA ROOT SIGNING SERVICE.

3.4 Identification and authentication for revocation request

In the event that a Participating CA requires the revocation of its certificate, the revocation request will be made by an authorized individual from the organization that has ownership of the Participating CA. The revocation request will be in writing and signed by an authorized individual of the organization. A revocation request in writing may be an electronic document such as e-mail with a digital signature from an authorized individual from the organization. The RSA ROOT SIGNING SERVICE will verify the revocation request using a telephone to contact the authorized individual and confirm the identity of the individual and the authenticity of the request. A detailed record of the request, confirmation of the request and action taken will be recorded by the RSA ROOT SIGNING SERVICE.

(21)

4 CERTIFICATE

LIFE-CYCLE

OPERATIONAL

REQUIREMENTS

4.1 Certificate

Application

The procedures and requirements with respect to an application for a certificate are set out in this CPS. An application for a certificate does not oblige the RSA ROOT SIGNING SERVICE to issue a certificate.

For this CPS, applications are for only Participating CA certificates. The application will follow the requirements for Sections 3.2.

4.1.1 Who can submit a certificate application

An application for a CA certificate will be made by a person authorized to act on behalf of an organization. Technical and administrative contacts will be identified including name, title, address, phone, e-mail. The application will follow the requirements for Section 3.1.6 “Authentication of organization” and 3.1.7 “Authentication of individual”.

The Participating CA will submit a CPS to the RSA ROOT SIGNING SERVICE for approval. The RSA ROOT SIGNING SERVICE has the right to approve or reject the submitted CPS, or provide recommendations for revising the proposed CPS to comply with the RSA ROOT SIGNING SERVICE CP. The CPS must be approved prior to the Participating CA submitting PKCS #10 Certificate Request for signature by one of the RSA CAs.

4.1.2 Enrollment process and responsibilities

A Subscriber (Participating CA) will enter into an agreement that outlines the terms and

conditions of use prior to the RSA CA’s signing and issuing a CA certificate to the Subscriber. A Subscriber will:

1. Have an agreed upon RSA Root Signing Agreement

2. Have a CPS that has been approved by the RSA ROOT SIGNING SERVICE

3. Have proper insurance coverage

4. Have agreements with their Subscribers and Relying Parties; and

5. Agree to abide by the RSA ROOT SIGNING SERVICE CP

6. If the participating CA will issue EV certificates, they must comply with the enrollment process and responsibilities as specified in the CA/Browser Forum’s Guidelines for EV Certificates.

4.2 Certificate

application processing

Individuals, as described in section 4.1, applying for certificates will follow the requirements of section 3.2. The Subscriber shall be tightly bound to their public keys and the information submitted. The CA Certificate Signing Process will be performed to sign the Participating CA’s certificate.

(22)

RSA Security Inc. Page 13 6/28/2007 4.2.1 Performing identification and authentication functions

The RSA CAs shall perform identification and authentication procedures to validate a certificate application. Following the validation, the CA will either approve or reject the certificate application, based on the criteria outlined in section 3.2.

Application for CA administrator or vetting certificates will be submitted by an entity designated by the RSA ROOT SIGNING SERVICE as having a need for and having met the requirements for such a certificate. The appropriate contact information will be identified including name, title, address, phone, and E-mail. The application will follow the requirements for Section 3.2.3. 4.2.2 Approval or rejection of certificate applications

The RSA ROOT SIGNING SERVICE shall notify a Subscriber that an RSA CA has created a certificate, and provide the Subscriber with the certificate. The CA may deliver the certificate through manual or automated processes.

A Subscriber will be notified in writing or by email of a rejected certificate application. 4.2.3 Time to process certificate applications

There is no stipulation for the period between the receipt of an application for a CA certificate and the signing of a CA certificate. Any stipulations will be based on contractual obligations.

4.3 Certificate

issuance

4.3.1 CA actions during certificate issuance

The issuance of a signed CA certificate by one of the RSA CAs indicates a complete and final approval of the certificate application by the CA.

4.3.2 Notification to subscriber by the CA of issuance of certificate

A Subscriber will be notified by the RSA ROOT SIGNING SERVICE that an RSA CA has created a certificate by providing the Subscriber with the certificate. The issuance notification will be in the form of an email message to the Subscriber informing of the successful completion of the

(23)

4.4 Certificate

acceptance

4.4.1 Conduct constituting certificate acceptance

The RSA ROOT SIGNING SERVICE will require that an entity acknowledge acceptance of a CA certificate. The signing of the CA certificate by one of the RSA CAs and the acceptance of the signed CA certificate by the organization will constitute acknowledgement and acceptance of the organization.

4.4.2 Publication of the certificate by the CA No stipulation.

4.4.3 Notification of certificate issuance by the CA to other entities

No notification of issuance or revocation will be provided to any other party when a certificate is issued or revoked except, in the case of revocation, through the issuance of a CRL or online certificate status services.

4.5 Key pair and certificate usage

4.5.1 Subscriber private key and certificate usage

The Subscriber shall only use certificates, issued by one of the RSA CAs, and their associated key pairs for the purposes identified in the RSA ROOT SIGNING SERVIVE CP, this CPS and in the RSA Root Signing Agreement.

4.5.2 Relying party public key and certificate usage

Prior to using a Subscriber's certificate, a Relying Party shall verify that the certificate is appropriate for the intended use. The rights and obligations of a Relying Party who is a

Participating CA in the RSA ROOT SIGNING SERVICE are covered in the RSA ROOT SIGNING SERVICE Certificate Policy.

4.6 Certificate

renewal

4.6.1 Circumstance for certificate renewal

Certificate renewal is the re-issuance of a certificate with a new validity date using the same public key corresponding to the same private key. Certificate renewal will be permitted within a mutually agreed upon time frame prior to certificate expiration.

4.6.2 Who may request renewal

(24)

RSA Security Inc. Page 15 6/28/2007 4.6.3 Processing certificate renewal requests

The RSA ROOT SIGNING SERVICE will authenticate all requests for certificate renewal from a Subscriber. Certificate renewal is bound by contractual obligations and will be defined in the RSA Root Signing Agreement. A Subscriber must present a valid certificate request in order to renew its certificate. If the certificate has expired the Subscriber will be authenticated in the same manner as the initial registration.

4.6.4 Notification of new certificate issuance to subscriber

A Subscriber will be notified by the RSA ROOT SIGNING SERVICE that the RSA CA has

renewed a certificate by providing the Subscriber with the certificate. The issuance notification will be in the form of an email message to the Subscriber informing of the successful completion of the renewal process.

4.6.5 Conduct constituting acceptance of a renewal certificate

The RSA ROOT SIGNING SERVICE will require that an entity acknowledge acceptance of a CA certificate. The signing of the CA certificate by the RSA CAs and the acceptance of the signed CA certificate by the organization will constitute acknowledgement and acceptance of the

organization.

4.6.6 Publication of the renewal certificate by the CA No stipulation.

4.6.7 Notification of certificate issuance by the CA to other entities

No notification of renewal will be provided to any other party when a certificate is renewed.

4.7 Certificate

re-key

4.7.1 Circumstance for certificate re-key

Re-key is not supported by the RSA ROOT SIGNING SERVICE. 4.7.2 Who may request certification of a new public key No stipulation.

4.7.3 Processing certificate re-keying requests No stipulation.

4.7.4 Notification of new certificate issuance to subscriber No stipulation.

4.7.5 Conduct constituting acceptance of a re-keyed certificate No stipulation.

(25)

4.7.7 Notification of certificate issuance by the CA to other entities No stipulation.

4.8 Certificate

modification

4.8.1 Circumstance for certificate modification

A certificate may be modified only at the discretion of the RSA ROOT SIGNING SERVICE Manager. Typically this would be under the following circumstances:

• When the basis for any information in the certificate changes.

• A change in the business relationship under which the certificate was issued occurs. 4.8.2 Who may request certificate modification

The authorized technical point of contact from the Participating CA’s organization may request certificate modification.

4.8.3 Processing certificate modification requests

All requests for certificate modification shall be submitted in writing. The authenticated

modification request and any resulting actions taken by the CA shall be recorded and retained as required.

4.8.4 Notification of new certificate issuance to subscriber

A Subscriber will be notified by the RSA ROOT SIGNING SERVICE that the RSA CA has renewed a certificate by providing the Subscriber with the certificate. The issuance notification will be in the form of an email message to the Subscriber informing of the successful completion of the renewal process.

4.8.5 Conduct constituting acceptance of a renewal certificate

The RSA ROOT SIGNING SERVICE will require that an entity acknowledge acceptance of a CA certificate. The signing of the CA certificate by the RSA CAs and the acceptance of the signed CA certificate by the organization will constitute acknowledgement and acceptance of the

organization.

4.8.6 Publication of the modified certificate by the CA No stipulation.

4.8.7 Notification of certificate issuance by the CA to other entities No stipulation.

4.9 Certificate

revocation and suspension

4.9.1 Circumstances for revocation

A CA certificate will be revoked:

(26)

RSA Security Inc. Page 17 6/28/2007 SERVICE suspects that conditions may lead to a compromise of the Participating CA’s keys or certificates.

• When any of the information in the certificate changes

• Upon suspected or known compromise of the Participating CA's private key

• Upon suspected or known compromise of media holding Participating CA's private key • When the Participating CA fails to comply with obligations set out in their CPS, any

agreement or any applicable law

• If the Participating CA fails a Compliance Audit or fails to submit an annual Compliance Audit report to the RSA ROOT SIGNING SERVICE

• Upon termination of the contract 4.9.2 Who can request revocation

The revocation of a CA certificate may only be requested by:

• The individual or organization which made the application for the certificate on behalf of an organization

• A duly appointed officer of the organization

• An authorized representative from the RSA ROOT SIGNING SERVICE 4.9.3 Procedure for revocation request

For the RSA ROOT SIGNING SERVICE, the revocation of a Participating CA certificate will require a written request from a duly appointed officer of an organization, or from the RSA ROOT SIGNING SERVICE Manager. The request for revocation of a Participating CA certificate will be verified prior to the revocation of the CA certificate. The verification process and contact will be determined in the RSA Root Signing Agreement.

Once the CA certificate is revoked it cannot be reinstated.

The RSA ROOT SIGNING SERVICE will keep a record of all revocation requests including the requestor's name, contact method, reason for revocation, date and time. A monthly report will be generated on all revocations.

All requests for revocation will be written and authenticated. The authenticated revocation request and any resulting actions taken by the RSA ROOT SIGNING SERVICE will be recorded and retained. In the case where a CA certificate is revoked, full justification for the revocation will also be documented.

Where a Participating CA certificate is revoked, the revocation will be published in the CRL. 4.9.4 Revocation request grace period

(27)

4.9.5 Time within which CA must process the revocation request

The period of time between the receipt of a valid request for certificate revocation and the processing of a certificate request will be a maximum of seven (7) business days.

4.9.6 Revocation checking requirement for relying parties

Prior to using a certificate, a Relying Party shall check the status of all certificates in the certificate validation chain against the appropriate and current CRL in accordance with the requirements stated in Sections 4.9 and 4.10. As part of this verification process the digital signature of the CRL will also be validated.

4.9.7 CRL issuance frequency

The RSA ROOT SIGNING SERVICE shall issue an up to date CRL to attest the most current certificate status of all issued certificates. The RSA ROOT SIGNING SERVICE shall synchronize, automatically or manually, its CRL issuance with an accessible web site or directory to provide accessibility of the most recent CRL to Relying Parties.

(28)

RSA Security Inc. Page 19 6/28/2007 4.9.8 Maximum latency for CRLs

A CA shall synchronize manually, its CRL issuance with an accessible directory or web site to provide accessibility of the most recent CRL to Relying Parties. The latency for the publishing of the CRL will be as the supporting technology will support; generally within one (1) business day. 4.9.9 Online revocation/status checking availability

The RSA ROOT SIGNING SERVICE will not support on line certificate revocation status checking for Participating CA certificates.

4.9.10 Online revocation checking requirements No stipulation.

4.9.11 Other forms of revocation advertisements available No stipulation.

4.9.12 Special requirements re key compromise No stipulation.

4.9.13 Circumstances for suspension Not supported by RSA ROOT SIGNING SERVICE. 4.9.14 Who can request suspension

Not supported by RSA ROOT SIGNING SERVICE. 4.9.15 Procedure for suspension request Not supported by RSA ROOT SIGNING SERVICE. 4.9.16 Limits on suspension period

Not supported by RSA ROOT SIGNING SERVICE.

4.10 Certificate status services

4.10.1 Operational characteristics The CRL access is at the following URLs:

http://www.rsasecurity.com/products/keon/repository/certificate_status/Valicert_Root_CA.CRL http://www.rsasecurity.com/products/keon/repository/certificate_status/RSA_Public_Root_CA.CRL http://www.rsasecurity.com/products/keon/repository/certificate_status/RSA_Security_2048_v3.CRL

(29)

4.10.2 Service availability

RSA ROOT SIGNING SERVICE will provide a current CRL that is accessible by Relying Parties and Subscribers for checking the status of all certificates in the certificate validation chain. The CRLs will be signed so that the authenticity and integrity of the CRLs can be verified.

4.10.3 Optional features No stipulation.

4.11 End of subscription

The end of a subscription as a result of no longer requiring the service, compromise, or termination of employment (voluntary or imposed) will be addressed in the manner indicated in the RSA Root Signing Agreement.

4.12 Key escrow and recovery

4.12.1 Key escrow and recovery policy and practices

Unless requested by the customer there will be no key escrow of CA keys. Please see Section 6.2.4 for more details.

(30)

5 FACILITY,

MANAGEMENT,

AND

OPERATIONAL

CONTROLS

5.1 Physical

controls

The RSA CAs are hosted at the CA Host Provider Site. The CA Host Provider provides physical security controls.

5.1.1 Site location, construction and physical access The CA site will:

• Be housed in a secure area within a secured building

• Have both manual and/or electronic monitoring for unauthorized intrusion at all times • Provide that unescorted access to the CA server is limited to those personnel identified

on an access list

• Require that personnel not on the access list be properly escorted and supervised • Require that a site access log is maintained and inspected periodically

• Require that all removable media and paper containing sensitive plaintext information is stored in containers that are physically secure such as a locked filing cabinet or a locked safe.

Please see the CA Hosting Service Provider documentation for further details. Please also see the Disaster Recovery Plan for further details.

5.1.1.1 Power and air conditioning Power will be conditioned through a UPS.

There will be sufficient air conditioning to maintain constant air temperature, humidity and airflow. 5.1.1.2 Protection from water exposure

There will be sufficient protection from water exposure. 5.1.1.3 Protection from fire exposure

There will be sufficient protection from fire exposure. 5.1.1.4 Storage media protection

Storage media will be sufficiently protected using tamper resistant and tamper evident containers. 5.1.1.5 Waste disposal

All media is disposed of properly. Confidential or sensitive paper is shredded prior to being placed for disposal. Magnetic media is degaussed or shredded prior to disposal.

5.1.1.6 Off-site backup

(31)

5.2 Procedural

controls

5.2.1 CA Trusted roles

In general, the RSA CAs will support a separation of duties for critical CA functions to prevent one person from maliciously using the CA system without detection. Each user's system access is to be limited to those actions for which they are required to perform in fulfilling their responsibilities. There must not be a conflict of interest between any position and the customers.

5.2.1.1 CA Administrator role

All RSA CA Administrators will be individually accountable for their actions. This will be accomplished by a combination of physical and electronic controls:

• Restricted access to facility – entry is monitored both entry and exit • Audit logs will record administrator log-in and log-out of system • Audit logs will record administrator log-in and log-out of CA

• Audit logs will record certificate creation, revocation, etc (see Section 4.5.1) 5.2.1.2 RA trusted roles

No stipulation.

5.2.1.3 Operating System Administrator role

The operating system hosting the RSA ROOT SIGNING SERVICE systems shall require a separation of duties for system-level tasks to prevent one person from maliciously using the CA server operating system without detection. Operating System Administrator access to the CA systems is to be limited to those actions they are required to perform in fulfilling their

responsibilities. These responsibilities shall be well understood by the Operating System Administrators. The Operating System Administrator cannot be a person that is also filling a CA Trusted role.

5.2.1.4 Validation Specialist role

RSA will maintain a Validation Specialist role for the purposes of certifying participating CAs that will issue EV SSL certificates. This Validation Specialist role will be in conformity with the role as described in the Guidelines for EV Certificates published by the CA/Browser forum.

5.2.2 Number of persons required per task

RSA ROOT SIGNING SERVICE Manager will provide the proper security and procedures such that no single individual may operate the CA without witnesses.

Multi-user control is also required for CA key generation as outlined in Section 6.2.2.

All other duties related to CA operations may be performed by an individual operating alone. CAs will have a verification process that provides an oversight of all activities performed by privileged CA role holders.

Please see the CA operations documentation for more details. 5.2.3 Identification and authentication for each role

(32)

RSA Security Inc. Page 23 6/28/2007 • Included in the access list for the CA site

• Included in the access list for physical access to the CA system • Given a certificate for the performance of their CA role

• Given an account on the PKI system.

Each of these certificates and accounts (with the exception of the CA signing certificates) will: • Be directly attributable to an individual

• Not be shared

• Be restricted to actions authorized for that role through the use of CA software, operating system and procedural controls.

5.2.4 Roles requiring separation of duties

The RSA CAs shall require a separation of duties for critical CA functions to prevent one person from maliciously using the CA system without detection. RSA will ensure CAs must enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the issuance of an EV Certificate.

5.3 Personnel

controls

The RSA ROOT SIGNING SERVICE requires that all personnel performing duties with respect to the operation of a CA or who are stakeholders in the management of the CA shall:

• Be appointed in writing

• Be bound by contract or statute to the terms and conditions of the position they are to fill • Have received comprehensive training with respect to the duties they are to perform • Be bound by contract or statute not to disclose sensitive CA security- relevant information

or Subscriber information; and

• Not be assigned duties that may cause conflict with their CA duties. 5.3.1 Qualifications, experience, and clearance requirements

The RSA ROOT SIGNING SERVICE requires that all personnel performing duties with respect to the operation of a CA have sufficient qualification and experience in PKI. All personnel must meet organizational personnel security requirements and CA Administrators shall have the following:

• PKI knowledge and training • Security training

• Product specific training; and

• No major observations in the background check verification 5.3.2 Background check procedures

All background checks will be performed in accordance with RSA standard organizational policies and procedures. All personnel considered for employment are thoroughly screened by a

reputable investigative agency:

1. Verification of the identity of such person. Verification of identity will be performed through: • The personal (physical) presence of such person before trusted persons who perform

human resource or security functions, and

(33)

2. Verification of the trustworthiness of such person. Verification of trustworthiness shall include background checks which address at least the following:

• Confirmation of previous employment • Check of professional references

• Confirmation of the highest or most relevant educational degree obtained

• Search of criminal records (local, state or provincial, and national) where allowed by the jurisdiction where the person will be employed

3. In the case of employees of the CA at the time of the adoption of this CPS whose identity and background has not previously been verified as set forth above, the CA shall conduct such verification within three (3) months of the date of adoption of this CPS.

Such screening will be repeated on a regular basis, not to exceed every 10 years. 5.3.3 Training requirements

The RSA CAs will require that for all personnel performing duties with respect to the operation of the CA will receive comprehensive training.

Requirements for employment:

1. All new employees that operate the CA will receive CA Administration training

2. All employees will receive specialized training based on current role and responsibilities. Position descriptions will be modified as necessary to maintain proficiency and compliance.

3. Intermediate training will be offered to refresh on changing PKI technologies as required

4. RSA will provide all personnel performing validation duties with skills training that cover basic Public Key Infrastructure (PKI) knowledge, authentication and verification policies and procedures, common threats to the validation process including phishing and other social engineering tactics, and the CA/Browser Forum EV Certificate Guidelines.

5. RSA will maintain records of such training and ensure that personnel entrusted with Validation Specialist duties meet a minimum skills requirement that enable them to perform such duties satisfactorily.

RSA will ensure that its Validation Specialists qualify for each skill level required by the corresponding validation task before granting privilege to perform said task.

RSA will require all Validation Specialists to pass an internal examination on the applicable EV Certificate validation criteria outlined in this CPS.

Disaster Recovery:

1. Business resumption plans will be exercised annually, or as necessary to test modifications made to the CA system

2. Site redundancy plans will be tested monthly, including power and HVAC resumption

3. The Administrators will become knowledgeable in the RSA ROOT SIGNING SERVICE Disaster Recovery Plan and the Business Resumption process it contains

5.3.4 Retraining frequency and requirements

The requirements for Section 5.3.3 shall be kept current to accommodate changes in a CA system (software and procedures). Refresher training shall be conducted as required, and management shall review these requirements once a year.

(34)

RSA Security Inc. Page 25 6/28/2007 In the event that there is job rotation, all passwords will be changed, user IDs deleted and

recreated. The RSA ROOT SIGNING SERVICE Manager will verify that all passwords have been changed and by the appropriate holder of that password. There is NO sharing of passwords. 5.3.6 Sanctions for unauthorized actions

In the event of actual or suspected unauthorized action by a person performing duties with respect to the operation of the RSA CAs, the RSA CAs may suspend his or her access to the CA system. The RSA CAs may revoke a certificate when an entity fails to comply with obligations set out in the RSA ROOT SIGNING SERVICE CP, the CPS, any agreement or applicable law. The RSA CAs may revoke a certificate at any time if the CA suspects that conditions may lead to a compromise of keys or certificates. If a person performs unauthorized actions that may jeopardize the safety, business, operations, data or customer, the RSA ROOT SIGNING SERVICE may, at its discretion, suspend, remove or reprimand the person depending on the severity of the results of the actions. The RSA ROOT SIGNING SERVICE may also seek remunerations and/or seek to lay criminal or civil charges against the perpetrator(s) of the action(s) and any other associated individuals or organizations.

5.3.7 Independent contractor requirements

The RSA CAs will require that contractor’s access to the CA site is in accordance with Section 5.1.1. Contracted personnel fulfilling a PKI role are subject to the same personnel controls as RSA ROOT SIGNING SERVICE employees, described in section 5.3 of this CPS.

5.3.8 Documentation supplied to personnel

(35)

5.4 Audit logging procedures

Audit log files are generated for all events relating to the security of RSA CAs. Where possible, the security audit logs are automatically collected. Where this is not possible, a logbook, paper form, or other physical mechanism will be used. All security audit logs, both electronic and non-electronic, will be retained and made available for compliance audits and legal review if required by law officials. The security audit logs for each auditable event defined in this section shall be maintained in accordance with Retention period for archive, Section 4.6.2.

5.4.1 Types of Events Recorded

All security type events including access, changes, generating keys, certificates, modifying keys, certificates, and any other event that may be required for auditing purposes will be recorded. The types of events are broken into two categories:

• Physical events such as building, room and vault access

• Logical events such as operating system operations and CA system operations Physical events may use electronic recording or logbooks. Video monitoring may be used in certain places where the physical presence of security personnel is not available.

Logical events will be recorded automatically in audit logs at the operating level and application level.

5.4.1.1 Physical Events

For Physical events the following will be recorded: • Date and time of event

• Identity of entity(ies)

• Action taken (i.e. entry into vault, exit from vault)

• Any other requirements that provide information pertaining to the event (could be comments regarding the replacement of a disk drive as to the failure)

The following physical events will be recorded: • Building or facility entry and exit • Secure area entry and exit • Safe entry and exit

• Equipment sign-out and return; and • CA system access

5.4.1.2 Logical Events

Logical events are divided into Operating System and CA System. For both events the following will be recorded in the form of an audit record.

• Type of event (application, system security, etc.) • Date and time the event occurred

• Success or failure of event

• Identity of the entity and/or operator of the CA that caused the event; and

• Any details about the event (may be error information or login message type information) Audit information will be kept, and audit logs should be signed to maintain integrity of the

(36)

Operating System

The following table represents audit events that will be monitored under the Windows operating system for either a successful action or a failing action.

Audit Event Type Success Failure Comments

Audit account logon events

Yes Yes Determines whether to audit each instance of a user logging on or logging off of another computer where this computer was used to validate the account.

Audit account management

Yes Yes _{Determines whether to audit each event of account} management on a computer. Examples of account management events include:

• A user account or group is created, changed, or deleted

• A user account is renamed, disabled, or enabled; or

• A password is set or changed Audit directory service

access

Yes Yes _{Determines whether to audit the event of a user} accessing an Active Directory object that has its own system access control list (SACL) specified. Audit logon events Yes Yes _{Determines whether to audit each instance of a}

user logging on, logging off, or making a network connection to this computer.

Audit object access Yes Yes Determines whether to audit the event of a user accessing an object (for example, file, folder, registry key, printer, and so forth) which has its own system access control list (SACL) specified. Audit policy change Yes Yes

Determines whether to audit every incidence of a change to user rights assignment policies, audit policies or trust policies.

Audit privilege use Yes Yes Determines whether to audit each instance of a user exercising a user right.

Audit process tracking Yes Yes

Determines whether to audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access.

THE RSA ROOT SIGNING SERVICE Certification Practice Statement For RSA Certificate Authorities (CAs) Published By: RSA Security Inc.