the rsa root signing service certification practice ... · the rsa root signing service...

THE RSA ROOT SIGNING SERVICE Certification Practice Statement

For RSA Certificate Authorities (CAs)

Last Revision Date: June 28, 2007

Version: 3.0

Published By: RSA Security Inc.

RSA Root Signing Service Certification Practice Statement (CPS) v. 3.0

RSA Security Inc. ii 6/28/2007

Copyright © 2002-2007 by RSA Security Inc.

All rights reserved. No part of this document may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without prior written permission of

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.

RSA Security, The Security Division of EMC2 heretofore known as RSA Security Inc; shall be

referenced in the text of the pages that follow as "RSA".


RSA Security Inc. iii 4/17/2007

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/ 3.0 6/28/2007 DF Incorporation of EV certificate validation.


RSA Security Inc. iv 6/28/2007

Table of Contents

OVERVIEW ..................................................................................................................................... 1 THE RSA ROOT SIGNING SERVICE PUBLIC KEY INFRASTRUCTURE HIERARCHY......................... 2

CPS SPECIFICATION .................................................................................................................... 3

1 INTRODUCTION...................................................................................................................... 3 1.1 OVERVIEW .......................................................................................................................... 3 1.2 DOCUMENT NAME AND IDENTIFICATION ................................................................................. 3 1.3 PKI PARTICIPANTS............................................................................................................... 3

1.3.1 Certification authorities .............................................................................................. 3 1.3.2 Registration authorities .............................................................................................. 4 1.3.3 Subscribers ................................................................................................................ 4 1.3.4 Relying parties ........................................................................................................... 4 1.3.5 Other participants....................................................................................................... 4

1.4 CERTIFICATE USAGE............................................................................................................ 4 1.4.1 Appropriate certificate uses ....................................................................................... 4 1.4.2 Prohibited certificate uses.......................................................................................... 5

1.5 POLICY ADMINISTRATION...................................................................................................... 5 1.5.1 Organization administering the document ................................................................. 5 1.5.2 Contact person........................................................................................................... 5 1.5.3 Person determining CPS suitability for the policy...................................................... 5 1.5.4 CPS approval procedures.......................................................................................... 5

1.6 DEFINITIONS AND ACRONYMS ............................................................................................... 5 2 PUBLICATION AND REPOSITORY RESPONSIBILITIES..................................................... 6

2.1 REPOSITORIES .................................................................................................................... 6 2.2 PUBLICATION OF CERTIFICATION INFORMATION...................................................................... 6 2.3 TIME OR FREQUENCY OF PUBLICATION.................................................................................. 6 2.4 ACCESS CONTROLS ON REPOSITORIES ................................................................................. 6

3 IDENTIFICATION AND AUTHENTICATION........................................................................... 8 3.1 NAMING .............................................................................................................................. 8

3.1.1 Types of names ......................................................................................................... 8 3.1.2 Need for names to be meaningful.............................................................................. 8 3.1.3 Anonymity or pseudonymity of subscribers ............................................................... 8 3.1.4 Rules for interpreting various name forms................................................................. 8 3.1.5 Uniqueness of names ................................................................................................ 8 3.1.6 Recognition, authentication, and role of trademarks ................................................. 8

3.2 INITIAL INDENTITY VALIDATION .............................................................................................. 9 3.2.1 Method to prove possession of private key ............................................................... 9 3.2.2 Authentication of organization identity ....................................................................... 9 3.2.3 Authentication of individual identity.......................................................................... 10 3.2.4 Non-verified subscriber information ......................................................................... 10 3.2.5 Validation of authority .............................................................................................. 10 3.2.6 Criteria for interoperation ......................................................................................... 10

3.3 IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS ............................................ 11 3.3.1 Identification and authentication for routine re-key.................................................. 11 3.3.2 Identification and authentication for re-key after revocation.................................... 11

3.4 IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST ...................................... 11 4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS........................................ 12

4.1 CERTIFICATE APPLICATION ................................................................................................ 12


RSA Security Inc. v 6/28/2007

4.1.1 Who can submit a certificate application ................................................................. 12 4.1.2 Enrollment process and responsibilities .................................................................. 12

4.2 CERTIFICATE APPLICATION PROCESSING............................................................................. 12 4.2.1 Performing identification and authentication functions ............................................ 13 4.2.2 Approval or rejection of certificate applications ....................................................... 13 4.2.3 Time to process certificate applications................................................................... 13

4.3 CERTIFICATE ISSUANCE ..................................................................................................... 13 4.3.1 CA actions during certificate issuance..................................................................... 13 4.3.2 Notification to subscriber by the CA of issuance of certificate................................. 13

4.4 CERTIFICATE ACCEPTANCE ................................................................................................ 14 4.4.1 Conduct constituting certificate acceptance ............................................................ 14 4.4.2 Publication of the certificate by the CA.................................................................... 14 4.4.3 Notification of certificate issuance by the CA to other entities................................. 14

4.5 KEY PAIR AND CERTIFICATE USAGE..................................................................................... 14 4.5.1 Subscriber private key and certificate usage........................................................... 14 4.5.2 Relying party public key and certificate usage ........................................................ 14

4.6 CERTIFICATE RENEWAL...................................................................................................... 14 4.6.1 Circumstance for certificate renewal........................................................................ 14 4.6.2 Who may request renewal ....................................................................................... 14 4.6.3 Processing certificate renewal requests .................................................................. 15 4.6.4 Notification of new certificate issuance to subscriber .............................................. 15 4.6.5 Conduct constituting acceptance of a renewal certificate........................................ 15 4.6.6 Publication of the renewal certificate by the CA ...................................................... 15 4.6.7 Notification of certificate issuance by the CA to other entities................................. 15

4.7 CERTIFICATE RE-KEY ......................................................................................................... 15 4.7.1 Circumstance for certificate re-key .......................................................................... 15 4.7.2 Who may request certification of a new public key.................................................. 15 4.7.3 Processing certificate re-keying requests ................................................................ 15 4.7.4 Notification of new certificate issuance to subscriber .............................................. 15 4.7.5 Conduct constituting acceptance of a re-keyed certificate ...................................... 15 4.7.6 Publication of the re-keyed certificate by the CA..................................................... 15 4.7.7 Notification of certificate issuance by the CA to other entities................................. 16

4.8 CERTIFICATE MODIFICATION ............................................................................................... 16 4.8.1 Circumstance for certificate modification................................................................. 16 4.8.2 Who may request certificate modification................................................................ 16 4.8.3 Processing certificate modification requests ........................................................... 16 4.8.4 Notification of new certificate issuance to subscriber .............................................. 16 4.8.5 Conduct constituting acceptance of a renewal certificate........................................ 16 4.8.6 Publication of the modified certificate by the CA ..................................................... 16 4.8.7 Notification of certificate issuance by the CA to other entities................................. 16

4.9 CERTIFICATE REVOCATION AND SUSPENSION ...................................................................... 16 4.9.1 Circumstances for revocation .................................................................................. 16 4.9.2 Who can request revocation .................................................................................... 17 4.9.3 Procedure for revocation request ............................................................................ 17 4.9.4 Revocation request grace period............................................................................. 17 4.9.5 Time within which CA must process the revocation request ................................... 18 4.9.6 Revocation checking requirement for relying parties............................................... 18 4.9.7 CRL issuance frequency.......................................................................................... 18 4.9.8 Maximum latency for CRLs...................................................................................... 19 4.9.9 Online revocation/status checking availability ......................................................... 19 4.9.10 Online revocation checking requirements ............................................................... 19 4.9.11 Other forms of revocation advertisements available ............................................... 19 4.9.12 Special requirements re key compromise................................................................ 19 4.9.13 Circumstances for suspension................................................................................. 19 4.9.14 Who can request suspension .................................................................................. 19 4.9.15 Procedure for suspension request........................................................................... 19


RSA Security Inc. vi 6/28/2007

4.9.16 Limits on suspension period .................................................................................... 19 4.10 CERTIFICATE STATUS SERVICES...................................................................................... 19

4.10.1 Operational characteristics ...................................................................................... 19 4.10.2 Service availability ................................................................................................... 20 4.10.3 Optional features...................................................................................................... 20

4.11 END OF SUBSCRIPTION................................................................................................... 20 4.12 KEY ESCROW AND RECOVERY......................................................................................... 20

4.12.1 Key escrow and recovery policy and practices........................................................ 20 4.12.2 Session key encapsulation and recovery policy and practices ............................... 20

5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS ........................................ 21 5.1 PHYSICAL CONTROLS......................................................................................................... 21

5.1.1 Site location, construction and physical access ...................................................... 21 5.2 PROCEDURAL CONTROLS................................................................................................... 22

5.2.1 CA Trusted roles ...................................................................................................... 22 5.2.2 Number of persons required per task ...................................................................... 22 5.2.3 Identification and authentication for each role ......................................................... 22 5.2.4 Roles requiring separation of duties ........................................................................ 23

5.3 PERSONNEL CONTROLS ..................................................................................................... 23 5.3.1 Qualifications, experience, and clearance requirements......................................... 23 5.3.2 Background check procedures ................................................................................ 23 5.3.3 Training requirements.............................................................................................. 24 5.3.4 Retraining frequency and requirements................................................................... 24 5.3.5 Job rotation frequency and sequence...................................................................... 24 5.3.6 Sanctions for unauthorized actions.......................................................................... 25 5.3.7 Independent contractor requirements...................................................................... 25 5.3.8 Documentation supplied to personnel ..................................................................... 25

5.4 AUDIT LOGGING PROCEDURES............................................................................................ 26 5.4.1 Types of Events Recorded ...................................................................................... 26 5.4.2 Frequency of processing data ................................................................................. 29 5.4.3 Retention period for Audit Log ................................................................................. 30 5.4.4 Protection of Audit Log............................................................................................. 30 5.4.5 Audit Log backup procedures .................................................................................. 30 5.4.6 Audit collection system (internal vs. external) ......................................................... 30 5.4.7 Notification to event-causing subject ....................................................................... 31 5.4.8 Vulnerability Assessments....................................................................................... 31

5.5 RECORDS ARCHIVAL.......................................................................................................... 31 5.5.1 Types of events archived......................................................................................... 31 5.5.2 Retention period for archive..................................................................................... 31 5.5.3 Protection of archive ................................................................................................ 32 5.5.4 Archive backup procedures ..................................................................................... 32 5.5.5 Requirements for Time-Stamping of Records ......................................................... 32

5.6 KEY CHANGEOVER............................................................................................................. 32 5.7 COMPROMISE AND DISASTER RECOVERY ........................................................................... 33 5.8 CA TERMINATION............................................................................................................... 33

5.8.1 RSA CAs termination............................................................................................... 33 5.8.2 Participating CA termination .................................................................................... 34

6 TECHNICAL SECURITY CONTROLS .................................................................................. 36 6.1 KEY PAIR GENERATION AND INSTALLATION .......................................................................... 36

6.1.1 Key pair generation.................................................................................................. 36 6.1.2 Private key delivery to subscriber ............................................................................ 36 6.1.3 Public key delivery to certificate issuer .................................................................... 36 6.1.4 CA public key delivery to relying parties .................................................................. 36 6.1.5 Key sizes.................................................................................................................. 36 6.1.6 Public key parameters generation and quality checking ......................................... 36


RSA Security Inc. vii 6/28/2007

6.1.7 Key usage purposes (as per X.509 v3 key usage field) .......................................... 37 6.2 PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS.......... 37

6.2.1 Cryptographic module standards and controls ........................................................ 37 6.2.2 Private key (n out of m) multi-person control ........................................................... 37 6.2.3 Private key escrow................................................................................................... 38 6.2.4 Private key backup................................................................................................... 38 6.2.5 Private key archival.................................................................................................. 38 6.2.6 Private key transfer into or from a cryptographic module ........................................ 38 6.2.7 Private key storage on cryptographic module ......................................................... 38 6.2.8 Method of activating private key .............................................................................. 38 6.2.9 Method of deactivating private key .......................................................................... 38 6.2.10 Method of destroying private key............................................................................. 38 6.2.11 Cryptographic Module Rating .................................................................................. 38

6.3 OTHER ASPECTS OF KEY PAIR MANAGEMENT....................................................................... 39 6.3.1 Public key archival ................................................................................................... 39 6.3.2 Certificate operational periods and key pair usage periods..................................... 39

6.4 ACTIVATION DATA .............................................................................................................. 39 6.4.1 Activation data generation and installation .............................................................. 39 6.4.2 Activation data protection ........................................................................................ 39 6.4.3 Other aspects of activation data .............................................................................. 39

6.5 COMPUTER SECURITY CONTROLS....................................................................................... 39 6.5.1 Specific computer security technical requirements ................................................. 39 6.5.2 Computer security rating.......................................................................................... 40

6.6 LIFE CYCLE TECHNICAL CONTROLS ..................................................................................... 40 6.6.1 System development controls.................................................................................. 40 6.6.2 Security management controls ................................................................................ 40 6.6.3 Life cycle security controls....................................................................................... 40

6.7 NETWORK SECURITY CONTROLS......................................................................................... 40 6.8 TIME-STAMPING................................................................................................................. 40

7 CERTIFICATE, CRL, AND OCSP PROFILES...................................................................... 41 7.1 CERTIFICATE PROFILE........................................................................................................ 41

7.1.1 Version number(s) ................................................................................................... 41 7.1.2 Certificate extensions............................................................................................... 42 7.1.3 Algorithm object identifiers....................................................................................... 42 7.1.4 Name forms ............................................................................................................. 42 7.1.5 Name constraints ..................................................................................................... 42 7.1.6 Certificate policy object identifier ............................................................................. 42 7.1.7 Usage of Policy Constraints extension .................................................................... 42 7.1.8 Policy qualifiers syntax and semantics .................................................................... 42 7.1.9 Processing semantics for the critical Certificate Policies extension ........................ 42

7.2 CRL PROFILE .................................................................................................................... 42 7.2.1 Version number........................................................................................................ 42 7.2.2 CRL and CRL entry extensions ............................................................................... 43

7.3 OCSP PROFILE ................................................................................................................. 43 7.3.1 Version number(s) ................................................................................................... 43 7.3.2 OCSP extensions..................................................................................................... 43

8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS ........................................................ 44 8.1.1 Compliance Audit..................................................................................................... 44

8.2 IDENTITY/QUALIFICATIONS OF ASSESSOR ........................................................................... 44 8.3 COMPLIANCE AUDITOR’S RELATIONSHIP TO ASSESSED ENTITY............................................ 44 8.4 TOPICS COVERED BY ASSESSMENT.................................................................................... 45 8.5 ACTIONS TAKEN AS A RESULT OF DEFICIENCY..................................................................... 45 8.6 COMMUNICATION OF RESULTS ........................................................................................... 45


RSA Security Inc. viii 6/28/2007

9 OTHER BUSINESS AND LEGAL MATTERS....................................................................... 46 9.1 FEES ................................................................................................................................ 46

9.1.1 Certificate issuance or renewal fees........................................................................ 46 9.1.2 Certificate access fees............................................................................................. 46 9.1.3 Revocation or status information access fees ......................................................... 46 9.1.4 Fees for other services ............................................................................................ 46 9.1.5 Refund policy ........................................................................................................... 46

9.2 FINANCIAL RESPONSIBILITY ................................................................................................ 46 9.2.1 Insurance coverage ................................................................................................. 46 9.2.2 Other assets............................................................................................................. 46 9.2.3 Insurance or warranty coverage for end-entities ..................................................... 46

9.3 CONFIDENTIALITY OF BUSINESS INFORMATION..................................................................... 47 9.3.1 Scope of confidential information............................................................................. 47 9.3.2 Information not within the scope of confidential information.................................... 47 9.3.3 Responsibility to protect confidential information .................................................... 47

9.4 PRIVACY OF PERSONAL INFORMATION................................................................................. 47 9.4.1 Privacy plan ............................................................................................................. 47 9.4.2 Information treated as private .................................................................................. 48 9.4.3 Information not deemed private ............................................................................... 48 9.4.4 Responsibility to protect private information............................................................ 48 9.4.5 Notice and consent to use private information ........................................................ 48 9.4.6 Disclosure pursuant to judicial or administrative process........................................ 48 9.4.7 Other information disclosure circumstances............................................................ 48

9.5 INTELLECTUAL PROPERTY RIGHTS ...................................................................................... 48 9.6 REPRESENTATIONS AND WARRANTIES ................................................................................ 48

9.6.1 CA representations and warranties ......................................................................... 49 9.6.2 RA representations and warranties ......................................................................... 49 9.6.3 Subscriber representations and warranties ............................................................. 49 9.6.4 Relying party representations and warranties ......................................................... 49 9.6.5 Representations and warranties of other participants ............................................. 49

9.7 DISCLAIMERS OF WARRANTIES ........................................................................................... 49 9.8 LIMITATIONS OF LIABILITY ................................................................................................... 50 9.9 INDEMNITIES...................................................................................................................... 50 9.10 TERM AND TERMINATION ................................................................................................ 50

9.10.1 Term......................................................................................................................... 50 9.10.2 Termination .............................................................................................................. 50 9.10.3 Effect of termination and survival............................................................................. 51

9.11 INDIVIDUAL NOTICES AND COMMUNICATIONS WITH PARTICIPANTS...................................... 51 9.12 AMENDMENTS................................................................................................................ 51

9.12.1 Procedure for amendment ....................................................................................... 51 9.12.2 Notification mechanism and period.......................................................................... 51 9.12.3 Circumstances under which OID must be changed ................................................ 51

9.13 DISPUTE RESOLUTION PROVISIONS ................................................................................. 51 9.13.1 Negotiation............................................................................................................... 52 9.13.2 Mediation ................................................................................................................. 52 9.13.3 Arbitration or litigation .............................................................................................. 52

9.14 GOVERNING LAW ........................................................................................................... 53 9.15 COMPLIANCE WITH APPLICABLE LAW ............................................................................... 53 9.16 MISCELLANEOUS PROVISIONS......................................................................................... 53

9.16.1 Entire agreement ..................................................................................................... 53 9.16.2 Assignment .............................................................................................................. 53 9.16.3 Severability .............................................................................................................. 53 9.16.4 Enforcement (attorneys' fees and waiver of rights) ................................................. 53 9.16.5 Force Majeure.......................................................................................................... 53

9.17 OTHER PROVISIONS ....................................................................................................... 53


RSA Security Inc. ix 6/28/2007

10 ACRONYMS....................................................................................................................... 54

11 DEFINITIONS ..................................................................................................................... 55


RSA Security Inc. Page 1 6/28/2007

OVERVIEW 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, liabilities, obligations, legal requirements, governing laws, processes, confidentiality, etc.



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 (http://www.cabforum.org). RSA complies with the version of the EV Certificate Guidelines adopted by the WebTrust Certification Authorities Advisory Group as the basis for WebTrust EV audit criteria. The Guidelines describe in detail what a CA must do in order to issue EV SSL certificates. Information about the issuing organization is displayed in a compatible browser that provides the end user a trustworthy confirmation of the identity of the entity that controls the website they are accessing.



CPS SPECIFICATION

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).

Participating CAs may sign Signature and/or Confidential certificates for end entities, devices and applications as well as sign certificates for subordinate CAs.



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:

• Authentication • Encryption • SSL/TLS • EV SSL/TLS • S/MIME email



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

A list of definitions and acronyms can be found at the end of this document.



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.

4. Provide, directly or through agreement with a repository that operating and repository access controls will be configured so that only authorized CA personnel can write or modify the online version of the CP; and



5. Provide full text version of the CPS when necessary for the purposes of audit, accreditation or cross-certification.



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

The priority to entity names will be given to registered trademark holders. The use of a Domain Name is restricted to the authenticated legal owner of that Domain Name. The use of an email address is restricted to the authenticated legal owner of that email address.



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 • Jurisdiction of Incorporation • Incorporating Agency • Address



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

Cross certification between external CAs and the RSA CAs will NOT be supported by the RSA ROOT SIGNING SERVICE.



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


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. The RSA ROOT SIGNING SERVICE will handle all revocation requests by customers. The revocation request will be logged by the RSA ROOT SIGNING SERVICE and all events subsequent to the revocation request will be recorded in this log.



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.

In processing the application for a Participating CA who will issue EV SSL certificates, RSA will verify to the effect that the entity is not considered or known to be a high risk.



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 enrollment process.



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

The RSA ROOT SIGNING SERVICE will accept requests for certificate renewal from the authorized technical point of contact from the Subscribing organization.



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.


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


4.7.2 Who may request certification of a new public key

No stipulation.

4.7.3 Processing certificate re-keying requests

No stipulation.


No stipulation.

4.7.5 Conduct constituting acceptance of a re-keyed certificate

No stipulation.

4.7.6 Publication of the re-keyed certificate by the CA

No stipulation.




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.


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.


No stipulation.

4.9 Certificate revocation and suspension

4.9.1 Circumstances for revocation

A CA certificate will be revoked: • When a Participating CA fails to comply with obligations set out in the RSA ROOT

SIGNING SERVICE CP, the CPS, any agreement or applicable law. The RSA ROOT SIGNING SERVICE may revoke a certificate at any time if the RSA ROOT SIGNING



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

The revocation grace period is the maximum period available, within which the Subscriber must make a revocation request upon suspicion of compromise. Any action taken as a result of a request for revocation will be initiated within seven (7) days of receipt of a revocation request.

Any other revocation request grace period will be defined in the RSA Root Signing Agreement; otherwise the provisions in this CPS are in force.



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. CRLs shall be updated to reflect most recent revocation. RSA will publish a new CRL within 24 hours from a certificate revocation. For any RSA CA which issues certificates to EV-compliant Participating CAs CRLs will be updated, if required, and reissued at least every seven (7) days, and with a maximum expiration time of ten (10) days. For any other CA’s in the RSA ROOT SIGNING SERVICE CRLs will be updated and reissued at least every twelve (12) months, and with a maximum expiration time of twelve (12) months.



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


4.9.15 Procedure for suspension request


4.9.16 Limits on suspension period


4.10 Certificate status services

4.10.1 Operational characteristics

The 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 http://www.rsasecurity.com/products/keon/repository/certificate_status/RSA_Public_Root_CA_v2.crl

The CRL distribution point will be identified in every certificate.



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.

4.12.2 Session key encapsulation and recovery policy and practices

No stipulation.



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 The off-site backup facility is rated at the same as the primary facility.



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

All CA personnel identity and authorization will be verified before they are:



• 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 • The verification of well-recognized forms of government-issued photo identification (e.g.,

passports and/or driver’s licenses); and



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.

5.3.5 Job rotation frequency and sequence



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

The RSA CAs will make available to its CA personnel the RSA ROOT SIGNING SERVICE CP, the CPS and any specific statutes, policies, procedures, documents and contracts relevant to their position. This includes Standard Operating Procedures, Subscriber Agreements, and Disaster Recovery Plans, Facilities Operations, Emergency Response Procedures and any other document required by personnel to perform their duties.



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 information.



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.

Audit system events Yes Yes Determines whether to audit when a user restarts or shuts down the computer; or an event has occurred that affects either the system security or the security log.



Windows 2000 records events in three kinds of logs:

Application log

The application log contains events logged by applications or programs. For example, a database program might record a file error in the application log. The developer decides which events to record.

System log

The system log contains events logged by the Windows operating system components. For example, the failure of a driver or other system component to load during startup is recorded in the system log. The event types logged by system components are predetermined.

Security log

The security log can record security events such as valid and invalid logon attempts, as well as events related to resource use, such as creating, opening, or deleting files. An administrator can specify what events are recorded in the security log. For example, if you have enabled logon auditing, attempts to log on to the system are recorded in the security log.

Event Viewer displays these types of events:

Error

A significant problem, such as loss of data or loss of functionality. For example, if a service fails to load during startup, an error will be logged.

Warning

An event that is not necessarily significant, but may indicate a possible future problem. For example, when disk space is low, a warning will be logged.

Information

An event that describes the successful operation of an application, driver, or service. For example, when a network driver loads successfully, an Information event will be logged.

Success Audit

An audited security access attempt that succeeds. For example, a user's successful attempt to log on to the system will be logged as a Success Audit event.

Failure Audit

An audited security access attempt that fails. For example, if a user tries to access a network drive and fails, the attempt will be logged as a Failure Audit event. The Event Log service starts automatically when you start the Windows operating system. Application and system logs can be viewed by all users, but security logs are accessible only to administrators.

CA System

CA System event logging lists the events that will be monitored in the CA system. The following events monitored will be logged for both success and failure:

• Key generation • Sign an end-entity certificate • Sign a CA certificate • Download an end-entity certificate to a client • Download a CA certificate to a client



• Download a Signer certificate to a client • Issue a CRL • Import a CRL • Resign a certificate • Create a new CA • Import a CA certificate from PKCS12 • Create a new administrator • Create a new vettor • Update a CA certificate • OCSP Transactions • Create a Signer Certificate • Sign a Signer Certificate • Reinstate a CA Certificate • Suspend a CA Certificate • Revoke a CA Certificate • Reinstate an end-entity Certificate • Suspend an end-entity Certificate • Revoke a certificate • Revoke a Signer Certificate

5.4.1.3 Consolidation requirements

Information pertaining to the RSA CAs on the following will be collected, consolidated and reported either electronically or manually:

• System configuration changes and maintenance • Personnel changes • Discrepancy and compromise reports • Correspondence with other PKI entities • Correspondence with CA related external parties such as network providers and software

suppliers • Destruction of media containing key material, activation data, or personal subscriber

information

5.4.2 Frequency of processing data

Audit logs will be reviewed in accordance to the table below. All significant events will be explained in an audit log summary. Such reviews involve verifying that the log has not been tampered with, and then briefly inspecting all log entries, with a more thorough investigation of any alerts or irregularities in the logs. Actions taken as a result of these reviews shall be documented.

The RSA ROOT SIGNING SERVICE review of Audit Logs

Audit logs will be reviewed at the end of each CA Certificate Signing Process and whenever the CA system is started and stopped. All audit logs will be reviewed, date and time stamped, stored and refreshed.

Statistically significant set of security audit data generated by RSA CAs since the last review shall be examined (where the confidence intervals for each category of security audit data are determined by the security ramifications of the category and the availability of tools to



perform such a review), as well as a reasonable search for any evidence of malicious activity.

For the RSA ROOT SIGNING SERVICE, 100% of security audit data generated by the RSA ROOT SIGNING SERVICE since the last review shall be examined.

5.4.3 Retention period for Audit Log

Audit logs shall be retained onsite for at least six months as well as being retained in the manner described below. The individual who removes audit logs from the RSA CAs system will be an official different from the individuals who, in combination, command the RSA CA’s signature key.

5.4.4 Protection of Audit Log

RSA CAs system configuration and procedures will be implemented together to ensure that: • Only authorized people have read access to the logs • Only authorized people may archive or delete audit logs • Audit logs are not modified.

Procedures will be implemented to protect archived data from deletion or destruction prior to the end of the audit log retention period (note that deletion requires modification access). Audit logs shall be moved to a safe, secure storage location separate from the RSA CA’s equipment.

5.4.5 Audit Log backup procedures

Audit logs and audit summaries will be backed up at the end of each certificate signing. A copy of the audit log will be sent off-site to RSA Administration for review and storage.

5.4.6 Audit collection system (internal vs. external)

The audit log collection system will be both manual and automatic. The collection system will involve physical security as part of the collection of audit information. Access to the building, room and vault where the CA system is stored and used will be monitored. Part of the monitoring may be recorded on video.

Operating System audit processes will be invoked at system startup, and cease only at operating system shutdown. CA System audit processes will be invoked at CA application startup and will cease only at CA system application shutdown. Should it become apparent that an automated audit system has failed, and the integrity of the system or confidentiality of the information protected by the system is at risk, then the RSA ROOT SIGNING SERVICE shall determine whether to suspend he RSA CA’s operation until the problem is remedied.

5.4.6.1 Audit log collection system

The audit collection system is both manual and automatic. Event Collection Point Automatic/Manual Recording Entity Building Entry Automatic Magnetic swipe card, video Secure Area Entry Manual Log sheet Safe Entry Manual Log sheet Equipment sign out of safe Manual Log sheet Operating System

• Application Log • System Log • Security Log

Automatic Windows Operating System

CA System • Web Server logs

Automatic RSA Certificate Manager (or KCA)



• Log Server logs The audit collection details for the Operating System, CA System can be found in the detailed CA Certificate Signing Process document.

5.4.7 Notification to event-causing subject

This CPS imposes no requirement to provide notice that an event was audited to the individual, organization, device, or application that caused the event.

5.4.8 Vulnerability Assessments Events in the audit process are logged, in part, to monitor system vulnerabilities. RSA CAs must ensure that a vulnerability assessment is performed, reviewed and action taken, as required, following an examination of these monitored events. RSA ROOT SIGNING SERVICE should present a summary report on the vulnerability assessment to management, highlighting any vulnerability found and the action taken to mitigate the vulnerability.

5.5 Records Archival

5.5.1 Types of events archived

RSA CAs archive records shall be sufficiently detailed to establish the proper operation of the RSA CAs, or the validity of any certificate (including those revoked or expired) issued by the RSA CAs.

At a minimum, the following data shall be recorded for archive: • RSA CA’s accreditation (if applicable) • Certificate Policy (each version) • Certification Practice Statement (each version) • Contractual obligations • System and equipment configuration • Modifications and updates to system or configuration • Certificate requests • Revocation requests • Subscriber identity Authentication data • Documentation of receipt and acceptance of certificates • Documentation of receipt of tokens • All certificates issued or published • Record of a CA Re-key • All CRLs issued and/or published • All Audit Logs • Other data or applications to verify archive contents • Documentation required by compliance auditors

5.5.2 Retention period for archive

The minimum retention period for archive data is seven (7) years. Customer information will only be kept for as long as the Customer is a valid Customer of RSA. Specific customer information will be disposed of according to disposal standards. Audit and other information relative to the operations and continuity of the CA will be kept.

If the original media cannot retain the data for the required period, a mechanism to periodically transfer the archived data to new media shall be defined by the archive site. Applications required



to process the archive data shall also be maintained for as long as necessary as determined by the RSA CAs.

Prior to the end of the archive retention period, the RSA CAs shall provide archived data and the applications necessary to read the archives to an approved archival facility, which shall retain the applications necessary to read this archived data.

5.5.3 Protection of archive

No unauthorized user shall be permitted to write to, modify, or delete the archive. For the RSA CAs, archived records may be moved to another medium when authorized by the RSA ROOT SIGNING SERVICE. The contents of the archive shall not be released except as determined by the RSA ROOT SIGNING SERVICE or as required by law. Records of individual transactions may be released upon request of any subscribers involved in the transaction or their legally recognized agents. Archive media shall be stored in a safe, secure storage facility separate from the RSA CAs.

Details of archival protection:

Access to the host computer system containing audit log files, certificates, CRLs, and keys is restricted to authorized personnel. Archival information will be protected in accordance with best practices.

Documents that have reached their end-of-life will be destroyed following proper disposition rules based on the classification of the document. For sensitive or confidential paper documents, the documents will be shredded prior to disposal. Any financial, certificate, audit, or control information on paper is considered confidential and will be shredded. Public documents may be placed in the disposal without shredding.

5.5.4 Archive backup procedures

Audit data is backed-up and securely stored in off-site storage facilities.

Certificates, CRLs and Keys are backed-up as part of the CA host system backup. Backup cartridges are stored locally in a fire-resistant container.

Cartridges containing a backup of the archive records are securely stored in off-site storage facility for long-term archival storage purposes.

Reports and correspondence is copied as it is received and securely stored in off-site storage facility. Original copies are kept in the offices of the RSA ROOT SIGNING SERVICE.

5.5.5 Requirements for Time-Stamping of Records

All documents archived pursuant to this section shall be marked with the date of their creation or execution.

5.6 Key changeover Participating CA key changeover is based on contractual obligations. Participating CA key changeover will occur prior to expiry of the contract.

Participating CA certificates will be set with an expiry period as defined in the RSA Root Signing Agreement. Based on contractual terms there will not be a need to re-sign a Participating CA certificate unless there is a change in the CA’s certificate. In some cases there may be a need to change the CA key. A key ceremony will be held to generate and sign a new CA key as required. Please see the RSA Root Signing Agreement for more details.



5.7 Compromise and Disaster Recovery All information pertaining to disaster recovery and business resumption are provided in the RSA ROOT SIGNING SERVICE Disaster Recovery Plan.

5.8 CA termination In the event that it is necessary for the RSA ROOT SIGNING SERVICE or one of its CAs to cease operation, the service will notify its Subscribers with reasonable notice prior to termination of operations and will create a termination plan to help minimize disruption to Subscribers and their relying parties. This plan may address the following:

1. The revocation of Subscriber certificates, if appropriate

2. The continued publication of certificate status information, as required

3. Arrangements for the disposition of the CA's keys and hardware tokens

4. Arrangements for the retention of CA archives in the manner and for the time indicated in Section 4.6. Unless a different custodian is indicated through notice to Subscribers, the Registered Agent for RSA shall be the custodian.

In the event of a change in management of a CA's operation, the CA will notify all entities for which it has issued certificates per the notification terms sets forth in the individual Customer agreements.

5.8.1 RSA CAs termination

In the event that any of the RSA CAs terminates for any reason, the RSA ROOT SIGNING SERVICE has an obligation to its customers to prepare for such an event. In the unlikely event of a compromise, the RSA ROOT SIGNING SERVICE will revoke and reissue all Participating CA certificates.

5.8.1.1 Compromise termination In the unlikely event that there is a compromise of any of the RSA CA’s key, all Participating CAs will be notified promptly. The process is further defined in the RSA ROOT SIGNING SERVICE Disaster Recovery Plan. Some key steps are:

• Notification of Participating CAs • Revocation of all keys • Key ceremonies (for all required CAs) • Reissue all new certificates • Investigation of compromise • Reporting results of investigation and required actions • Implement actions

Please see the RSA ROOT SIGNING SERVICE Disaster Recovery Plan for more details on termination.

5.8.1.2 End of life termination In the unlikely event that any of the RSA CAs terminates, the applicable RSA CA will notify all Participating CAs. Keys may be revoked or there may be a turnover of keys to a new Certification Authority Service who will maintain the operations along with the keys.



5.8.2 Participating CA termination

There are two possible scenarios where a Participating CA will be terminated: • Compromise, where the CA private key has been or is suspected of being compromised,

or • End of contract termination

5.8.2.1 Compromise termination In the event of a compromise of a Participating CA, notification will be sent to all other Participating CAs and an investigation of the compromise by the RSA ROOT SIGNING SERVICE and the Participating CA will be immediately investigated. The CA certificate will be revoked by the appropriate RSA CA and a CRL will be posted.

The Participating CA must abide by the terms of the RSA Root Signing Agreement provisions with respect to compromise.

In the event of a compromise of any of the RSA CA’s private signing key, the RSA ROOT SIGNING SERVICE will notify all Participating CAs chained to the compromised CA, revoke all such CAs’ certificates and revoke the compromised RSA CA certificate. Notification will be a signed e-mail and with a confirming phone call. The key steps taken as a result of a compromise are:

• Notification of all Participating CAs • Revocation of all keys • Key ceremonies (if required for CAs) • Resign and reissue all new CA certificates • Investigation of compromise • Reporting results of investigation and required actions • Implementing actions

It is important to note that the investigation starts immediately upon notification of compromise and the results may require additional steps and directly impact on the key ceremony and reissue of certificates.

End entities will notify the CA of any compromise even though end entities can revoke their own certificates. All revocations of certificates will be reviewed by the Security Officer to determine if further action is required. The review will consider if the end entity should be allowed to obtain another certificate (risk assessment to determine if the end entity is a risk to the integrity and safety of the CA).

5.8.2.2 End of contract termination There are three possible scenarios that may occur at the end of contract for a Participating CA:

• CA terminates • CA renews, or • CA removes chaining

CA terminates

If a Participating CA terminates, its certificate will be revoked by the RSA CA and the Participating CA will remove the CA certificate and all end entity certificates from use per the terms of the RSA Root Signing Agreement. Depending on legislation, there may be a requirement to keep or destroy all personnel records.



CA renews

If the Participating CA renews the RSA Root Signing Agreement, the CA certificate(s) may need to be re-signed. The renewal must occur prior to the expiry of the CA certificate or else the CA will be required to undergo renewal of the CA certificate as if it was a new CA.

CA removes chaining

If the Participating CA determines that they will not maintain the chaining with the RSA CAs, the Participating CA certificates must be destroyed. A customized plan for such an event will be created to properly destroy the certificates once the CA has removed the chaining. A letter from the Participating CA indicating that the CA certificate was properly disposed of must be issued by the Participating CA per the terms of the RSA Root Signing Agreement.


Confidential Page 36

6 TECHNICAL SECURITY CONTROLS

6.1 Key pair generation and installation

6.1.1 Key pair generation

CA key pair generation will be from a Secure Cryptographic Hardware Security Module (HSM) rated at least FIPS PUB 140-2, level 3. Subscriber key pair generation will be supported in hardware as stipulated in section 6.1.6.

6.1.2 Private key delivery to subscriber

No stipulation.

6.1.3 Public key delivery to certificate issuer

All Subscriber public-keys and certificates will be stored in the CA’s repository. Delivery of Subscribers public keys, from the Subscribers themselves shall be in PKCS #10 Certificate Signing Request (CSR) format.

6.1.4 CA public key delivery to relying parties

All Public keys and certificates will be stored in the CA’s repository. The RSA ROOT SIGNING SERVICE public keys (as part of its certificate) shall be delivered to a Subscriber as part of the issuing process. The format will be PKCS #7 (binary or base64), with or without chain, depending on the Subscriber’s requirements.

6.1.5 Key sizes

The RSA CAs will use the RSA cryptography key algorithm with a minimum key length of 1024 bits.

6.1.6 Public key parameters generation and quality checking

6.1.6.1 CA key generation

RSA ROOT SIGNING SERVICE Signature keys shall be generated using a random or pseudo-random process as described in ISO 9564-1 and ISO 11568-5 that are capable of satisfying the statistical tests of FIPS PUB 140-2, level 3. CA Keys are to be protected by a hardware cryptographic module rated at least FIPS 140-2 Level 3.

6.1.6.1.1 Key generation ceremony For the generation of the RSA CAs keys, the key ceremony will require the presence of witnesses to sign-off on the process. A formal key ceremony will have the following present:

• Necessary hardware and software to support key generation on chosen HSM technology and the equipment to support the key generation ceremony

• One or two witnesses for key ceremony • Secured facility where attendees will sign in • Record of all attendees



• Record of proceedings • Copy of CA key for backup, Disaster Recovery, and • Proper storage of copy (clone) in a tamper resistant and temper evidence container

Certificate Signing Process

The signing of a Participating CA certificate will require that a customer has agreed to be compliant with the RSA ROOT SIGNING SERVICE CP and has signed the appropriate agreements and contracts. The customer must provide a CPS and the RSA ROOT SIGNING SERVICE must approve of the CPS prior to the Certificate Signing Process.

6.1.6.2 Subscriber key generation

Participating CAs shall generate signature keys using a random or pseudo-random process as described in ISO 9564-1 and ISO 11568-5 that are capable of satisfying the statistical tests of FIPS PUB 140-2, level 3. Subordinate CA Keys are to be protected by a secure cryptographic hardware module rated at least FIPS 140-2 level 3.

Key pairs for all other Subscribers may be generated and stored in software or protected by secure cryptographic hardware module (e.g. smartcards) at the discretion of the issuing Participating CA PKI Policy Management Authority.

6.1.7 Key usage purposes (as per X.509 v3 key usage field)

See section 7 for key usage as per Section 7.1.1 base certificates and 7.1.2 certificate extensions.

The RSA CA’s private key will be used only for signing CA certificates and CRLs and in the extraordinary circumstance where a certificate may be required for test purposes.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

CA Keys are to be protected by a secure cryptographic hardware module rated at FIPS 140-2, Level 3 or higher.

The Subscriber is responsible for its private keys and shall protect its private key from disclosure according to the requirements as defined by their CPS and the RSA Root Signing Agreement. Private Keys are only to be used for the intended purpose as defined by the certificate profile (section 7) and the RSA Root Signing Agreement. The RSA ROOT SIGNING SERVICE Policy Management Authority may grant exceptions.

6.2.1 Cryptographic module standards and controls

All CA digital signature key generation, CA digital signature key storage and certificate signing operations shall be performed in a secure cryptographic hardware module rated to at least FIPS 140-2 Level 3 or otherwise verified to an equivalent level of functionality and assurance.

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

There shall be multiple person control for CA key generation operations. At a minimum, there shall be multi-person control for operational procedures such that no one person can gain control over the CA signing key. The principle of split knowledge and dual control as defined in section 5.2.2 shall be applied.



6.2.3 Private key escrow

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

6.2.4 Private key backup

The RSA CA’s private and public duplicate keys are stored in a tamper resistant and tamper evidenced containers offsite. More detail is contained within the RSA ROOT SIGNING SERVICE Disaster Recovery Plan.

6.2.5 Private key archival

Refer to Section 5.5.

6.2.6 Private key transfer into or from a cryptographic module

No stipulation.

6.2.7 Private key storage on cryptographic module

CA digital signature key storage shall be kept on a secure cryptographic hardware module rated to at least FIPS 140-2 Level 3.

6.2.8 Method of activating private key

The Entity must be authenticated to the cryptographic module before the activation of the private key. This authentication will be per section 6.2.2. When deactivated, private keys must be kept in encrypted form only.

6.2.9 Method of deactivating private key

When keys are deactivated the application must clear the keys from memory before the memory is de-allocated. Any disk space where keys were stored must be over-written before the space is released to the operating system. The cryptographic module must automatically deactivate the private key after a pre-set period of inactivity.

6.2.10 Method of destroying private key

Upon termination of use of a private key, over-writing must securely destroy all copies of the private key in computer memory and shared disk space. Private key destruction procedures will be described in appropriate operations procedures.

6.2.11 Cryptographic Module Rating

All CA digital signature key generation, CA digital signature key storage and certificate signing operations shall be performed in a secure cryptographic hardware module rated to at least FIPS 140-2 Level 3.



6.3 Other aspects of key pair management

6.3.1 Public key archival The RSA CAs will retain all verification public keys as required. The retention of CA public keys will be based on contractual requirements. In any event unless otherwise authorized by the customer, keys will be kept for seven (7) years as per Section 4.6 Records Archival. The RSA CAs’ public keys will be retained for seven (7) years after the validity period of the keys expires.

6.3.2 Certificate operational periods and key pair usage periods

The RSA CA Keys will be valid until 2019 and 2026 respectively. The actual usage period of the RSA CA Keys may be less than the validity period depending on customer requirements. Participating CA keys usage periods will be determined in the contract.

6.4 Activation data

6.4.1 Activation data generation and installation

If activation data is used it must be unique and unpredictable.

6.4.2 Activation data protection

If activation data is used it, it must be protected from unauthorized use by a combination of cryptographic and physical access control mechanisms.

6.4.3 Other aspects of activation data

No stipulation.

6.5 Computer security controls

6.5.1 Specific computer security technical requirements

The following functionality may be provided by the operating system, or through a combination of operating system, PKI CA software, and physical safeguards (policies and procedures). Each CA server will include the following functionality:

• Access control to CA services and PKI roles, see Section 5.1 • Enforced separation of duties for PKI roles, see Section 5.2 • Identification and authentication of PKI roles and associated identities, see Section 5.3 • Use of cryptography for session communication and database security, mutually

authenticated and encrypted SSL/TLS is used for all communications • Archival of CA history and audit data, see Sections 4.5 and 4.6 • Audit of security related events, see Section 4.5 • Trusted path for identification of PKI roles and associated identities, use of X.509

certificates for all administrators • Recovery mechanisms for CA keys and CA system. See Section 5.7 and the Disaster

Recovery plan



6.5.2 Computer security rating

No stipulation.

6.6 Life cycle technical controls

6.6.1 System development controls

The RSA Certificate Management product will follow the Certificate Issuing and Management Components (CIMC) Family of Protection Profiles that defines requirements for components that issue, revoke, and manage public key certificates, such as X.509 public key certificates. The CIMC is based on the Common Criteria/ISO IS15408 standards (http://csrc.nist.gov/cc/ccv20/ccv2list.htm).

6.6.2 Security management controls

A formal configuration management methodology will be used for installation and ongoing maintenance of the CA system. The CA software, when first loaded will provide a method for the CA to verify that the software on the system:

• Originated from the software developer • Has not been modified prior to installation, and • Is the version intended for use?

CAs will provide a mechanism to periodically verify the integrity of the software.

CAs will have mechanisms and policies in place to control and monitor the configuration of the CA system.

Upon installation and as required the integrity of the CA system will be validated.

6.6.3 Life cycle security controls

No stipulation.

6.7 Network security controls The RSA CA’s server will not be connected to external networks.

6.8 Time-stamping

No trusted time source is required for RSA ROOT SIGNING SERVICE operations. The requirement for time-stamping of data is applicable to archives as described in section 5.5.5.



7 CERTIFICATE, CRL, AND OCSP PROFILES

7.1 Certificate profile

7.1.1 Version number(s)

RSA ROOT SIGNING SERVICE shall issue X.509 Version 3 certificates, in accordance with the PKIX Certificate and CRL Profile. The PKI end entity software shall support all the base (non-extension) X.509 fields as well as any certificate extensions defined in this CPS.

7.1.1.1 Base certificate format

The Base Certificate Format will conform to the X.509 standard. The following represents the base certificate fields supported. Additional extensions are allowable if required.

Certificate Field Description

Version indicates version number of certificate (version 3 is indicated as a "2")

Serial Number unique identifying number for this certificate assigned by the issuing CA

Signature Algorithm identifier of the digital signature algorithm used by the CA to sign the certificate

Issuer X.500 name of the issuing CA Validity Start and expiry dates and times of the certificate

Subject X.500 name of the holder of the private key for which the corresponding public key is being certified

Subject public key information The value of the public key for the subject along with an identifier of the algorithm with which this public key is to be used

Issuer unique identifier An optional bit string that may be used to make the issuing CA name unambiguous

Subject unique identifier An optional bit string used to make the subject name unambiguous



7.1.2 Certificate extensions

7.1.2.1 CA Certificates

The RSA CAs which sign participating CAs will support Version 3 extensions.

The RSA CAs will support CA extensions according to PKIX Internet Draft “Internet X.509 Public Key Infrastructure Certificate and CRL Profile http://www.ietf.org/rfc/rfc3280.txt

7.1.3 Algorithm object identifiers

The RSA CAs will use and support, for signing and verification, the following algorithms: • RSA 1024 in accordance with PKCS#1 (as found in RFC 2313), and • RSA 2048 in accordance with PKCS#1 (as found in RFC 2313), and • SHA-1 in accordance with FIPS PUB 180-1 and ANSI X9.30 part2.

7.1.4 Name forms

Every DN must be in the form of an X.501 DirectoryString. Certificates issued by a CA contain the full X.500 distinguished name of the Certificate issuer and Certificate subject in the issuer name and subject name fields.

7.1.5 Name constraints

Subject and Issuer DNs must comply with PKIX standards and be present in all certificates.

7.1.6 Certificate policy object identifier

Where the Certificate Policies extension is used, certificates contain the object identifier for the Certificate Policy corresponding to the appropriate certificate as set forth in this CPS.

7.1.7 Usage of Policy Constraints extension

No stipulation.

7.1.8 Policy qualifiers syntax and semantics

RSA ROOT SIGNING SERVICE populates X.509 Version 3 certificates with a policy qualifier within the Certificate Policies extension. Generally, such certificates contain a CPS pointer qualifier that points to the Participating CA CPS. In addition, some Certificates contain a User Notice Qualifier which may point to an applicable Relying Party Agreement.

7.1.9 Processing semantics for the critical Certificate Policies extension

Critical extensions, when applicable, shall be interpreted as defined in PKIX.

7.2 CRL profile

7.2.1 Version number

CAs will issue X.509 version 2 CRLs in accordance with the PKIX Certificate and CRL Profile.



7.2.2 CRL and CRL entry extensions

The RSA CAs will support and use all CRL Version 2 extensions required in the PKIX Certificate and CRL Profile. Certificate revocation codes will not be supported.

7.3 OCSP profile

7.3.1 Version number(s)

No stipulation.

7.3.2 OCSP extensions

No stipulation.



8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS A Compliance Audit provides an independent third party attestation that the CA is operating as stated in the CP and this CPS. The RSA CAs will have a Compliance Audit performed to the WebTrust Principles and Criteria for Certificate Authorities.

8.1.1 Compliance Audit

A third party independent Compliance Audit will be performed annually to certify the compliance of the RSA CAs with both the WebTrust Certification Authorities audit criteria and the WebTrust EV Program.

WebTrust for Certification Authorities reports on the compliance of Certificate Authorities with the WebTrust Principles and Criteria for Certificate Authorities Version 2.0 (document is available at http://www.webtrust.org ). WebTrust for Certificate Authorities was designed for the examination of Certificate Authority business activities.

8.1.1.1 Frequency of Assessment A Compliance Audit will be performed annually and as required to obtain a WebTrust Certification Authorities Seal.

WebTrust requires continuous coverage from the point of initial qualification. Qualification after compliance can be tested over a minimum two-month period with updates occurring annually.

8.2 Identity/Qualifications of Assessor

The auditor must demonstrate competence in the field of compliance audits, and must be thoroughly familiar with requirements which the RSA ROOT SIGNING SERVICE imposes on the issuance and management of all certificates, and which Customers impose on the issuance and management of their certificates. The Compliance Auditor should perform such Compliance Audits as a primary responsibility.

The Compliance Auditor must be a practitioner who has a WebTrust Business license from the American Institute of Certified Professional Accountants (AICPA) or the Canadian Institute of Chartered Accountants (CICA), or other authorized national accounting institute.

The Compliance Auditor will be independent of the RSA CAs and will have proper credentials to positively identify the Compliance Auditor as belonging to a recognized audit firm.

The Compliance Auditor will be a qualified auditor as defined by the CA/Browser Forum’s Guidelines for EV Certificates.

8.3 Compliance Auditor’s Relationship to Assessed Entity

For the RSA ROOT SIGNING SERVICE the Compliance Auditor either shall be a private firm, which is independent from the entity being audited, or it shall be sufficiently organizationally separated from that entity to provide an unbiased, independent evaluation and attestation. The RSA ROOT SIGNING SERVICE shall determine whether a Compliance Auditor meets this requirement.



8.4 Topics Covered by Assessment

The purpose of a yearly compliance audit shall be to verify that an entity subject to the requirements of the CP and this CPS, is complying with the requirements of those documents. Together, the third party auditor and the RSA ROOT SIGNING SERVICE shall determine and agree to all audit program and audit criteria. The Compliance Audit will cover all requirements as defined for WebTrust such as:

• CA business practices disclosure • Service integrity (including key and certificate life cycle management activities) • CA environmental controls

8.5 Actions taken as a Result of Deficiency

When the Compliance Auditor finds a discrepancy between how the CA is designed or is being operated or maintained, and the requirements of this CPS and the RSA ROOT SIGNING SERVICE CP, the following actions may be taken depending on the severity of the discrepancy (ies):

• If the discrepancy is minor, the Compliance Auditor shall note the discrepancy as part of the Compliance Audit report.

• If the discrepancy is of magnitude to deny or remove WebTrust Certification Authorities Seal, the Compliance Auditor shall meet with the RSA ROOT SIGNING SERVICE Manager. The RSA ROOT SIGNING SERVICE Manager will determine how to remedy the discrepancy and discuss with the Compliance Auditor if the remedy is sufficient to gain or retain the WebTrust Certification Authorities Seal. An action plan with a distinct timeframe for implementing the remedy and a final report detailing the discrepancy, remedy and final outcome will be required. These will be reviewed by the RSA ROOT SIGNING SERVICE Manager and the Compliance Auditor. A final decision by the Compliance Auditor will be binding and if, in the judgment of the Compliance Auditor, the discrepancy is still severe, the WebTrust Certification Authorities Seal may be removed.

• All discrepancies will be reviewed by the Policy Management Authority and an action plan will be developed to remedy or reduce any discrepancy.

8.6 Communication of Results A Compliance Audit Report will be produced by the Compliance Auditor. The Compliance Audit Report will be used by the RSA ROOT SIGNING SERVICE to obtain and maintain a WebTrust Certification Authorities Seal. All audit reports to include any corrective action taken will remain the sole property of the audited CA and will be treated as confidential and protected accordingly. A summary of the report should be submitted to the management of the CA.



9 OTHER BUSINESS AND LEGAL MATTERS

9.1 Fees

The charging of fees is subject to the appropriate authority and policy. Notice of any fee charged to a Subscriber or Relying Party will be brought to the attention of that entity.

9.1.1 Certificate issuance or renewal fees

Fee structures for Participating CAs will be provided in the RSA Root Signing Agreement.

9.1.2 Certificate access fees

No stipulation.

9.1.3 Revocation or status information access fees

No stipulation.

9.1.4 Fees for other services

Unless otherwise agreed to in another contractual relationship, RSA ROOT SIGNING SERVICE shall be responsible for all administrative expenses associated with the operation of the RSA CAs including compliance auditing under section 8 of this document.

9.1.5 Refund policy

Refunds for Participating CAs are described in the applicable RSA Root Signing Agreement.

9.2 Financial responsibility

This section is not meant to replace the liability and indemnifications provisions of any RSA Root Signing Agreement, which will continue to be enforced and in effect.

9.2.1 Insurance coverage

The RSA ROOT SIGNING SERVICE will maintain adequate levels of insurance necessary to support its business practices.

9.2.2 Other assets

No stipulation.

9.2.3 Insurance or warranty coverage for end-entities

RSA ROOT SIGNING SERVICE is not a trustee, agent, fiduciary, or other representative of the Subscriber and the relationship between the RSA ROOT SIGNING SERVICE and the Subscriber is not that of an agent and a principal. RSA ROOT SIGNING SERVICE makes no representation to the contrary, either implicitly, explicitly, by appearance or otherwise. The Subscriber does not have any authority to bind RSA ROOT SIGNING SERVICE by contract, agreement or otherwise, to any obligation.



9.3 Confidentiality of business information

9.3.1 Scope of confidential information

Corporate information held by a CA, not appearing in certificates or in public directories (e.g. registration and revocation information, logged events, correspondence between Subscriber and CA, etc.) is considered confidential and will not be disclosed without the prior consent of the Subscriber unless required by law.

Audit and review information is to be considered confidential and will not be disclosed to anyone for any purpose other than audit purposes or where required by law.

Information pertaining to the CA's management of a Subscriber's digital signature certificate may only be disclosed to the Subscriber or where required by law.

Any disclosure of information is subject to the requirements of any Privacy Laws and any other relevant legislation and applicable organizational policy.

The digital signature private key of each Subscriber is to be held only by the Subscriber and must be kept confidential by them. Any disclosure by the Subscriber is at the Subscriber's own risk.

Any request for the disclosure of information shall be signed by the requester and delivered in writing to the RSA ROOT SIGNING SERVICE. Any disclosure of information is subject to the requirements of any privacy laws and any other relevant legislation and applicable organizational policy.

9.3.2 Information not within the scope of confidential information

Certificates, CRLs and corporate information appearing on them and in public directories are not considered confidential. Additionally, information that meets the following criteria shall not be considered to be confidential information:

• Information that is documented by the receiving party as having been independently developed by it without unauthorized reference to or reliance on the confidential information of the disclosing party

• Information that the receiving party lawfully receives free of restriction from a source other than the disclosing party

• Information that is or becomes generally available to the public through no wrongful act or omission on the part of the receiving party

• Information that at the time of disclosure to the receiving party was known to the receiving party free of restriction as evidenced by documentation in the receiving party’s possession, or

• Information that the disclosing party agrees in writing is free of restrictions

9.3.3 Responsibility to protect confidential information

RSA ROOT SIGNING SERVICE must ensure that confidential information be physically and/or logically protected from unauthorized viewing, modification or deletion. In addition, the RSA ROOT SIGNING SERVICE must ensure that storage media used by the CA systems is protected from environmental threats such as temperature, humidity and magnetism.

9.4 Privacy of personal information

9.4.1 Privacy plan



RSA ROOT SIGNING SERVICE policy is to not disclose private personal information of its Subscribers, customers, employees, partners, etc. without the prior consent of the aforementioned unless required by law.

9.4.2 Information treated as private

Personal information, not appearing in certificates and in public directories, held by a CA (e.g. registration and revocation information, logged events, correspondence between Subscriber and CA, etc.) is considered private and shall not be disclosed by the CAs.

9.4.3 Information not deemed private

Personal information that is publicly available, appearing in certificates and in public directories, is not considered private.

9.4.4 Responsibility to protect private information

RSA ROOT SIGNING SERVICE shall ensure that private personal information be physically and/or logically protected from unauthorized viewing, modification or deletion. In addition, the RSA ROOT SIGNING SERVICE shall ensure that storage media used by the CA systems is protected from environmental threats such as temperature, humidity and magnetism.

9.4.5 Notice and consent to use private information

Private personal information will only be utilized without prior consent as per section 9.4.1.

9.4.6 Disclosure pursuant to judicial or administrative process

Private personal information will only be disclosed if required by law as per section 9.4.1.

Any request for the disclosure of private information shall be signed by the requester and delivered in writing to the RSA ROOT SIGNING SERVICE. Any disclosure of private information is subject to the requirements of any privacy laws and any other relevant legislation and applicable organizational policy.

9.4.7 Other information disclosure circumstances

No stipulation.

9.5 Intellectual property rights

The private key shall be the sole property of the legitimate holder of the corresponding Public Key identified in a certificate.

A CA retains all intellectual property rights in and to the Certificates and revocation information that they issue. RSA and Customers shall grant permission to reproduce and distribute Certificates on a nonexclusive royalty-free basis, so long as they are reproduced in full and that use of Certificates is subject to the terms of all Policies referenced in the Certificate.

RSA retains all intellectual property rights in and to this CPS.

9.6 Representations and warranties

The RSA ROOT SIGNING SERVICE will issue and revoke certificates, operate its certification and repository services, and issue CRLs in accordance with the RSA ROOT SIGNING SERVICE CP and this CPS.



Authentication and validation procedures will be implemented as set forth in Section 3 of this CPS.

9.6.1 CA representations and warranties

The RSA CAs will operate their certification and repository services, will issue and revoke certificates, and will issue CRLs in accordance with its RSA ROOT SIGNING SERVICE CP and this CPS.

Authentication and validation procedures will be implemented as set forth in Section 3 of this CPS.

CA personnel associated with PKI roles shall be individually accountable for actions they perform. The phrase "Individually accountable" means that there shall be evidence (logs) that attributes an action to the person performing the action.

The RSA CAs, under this CPS, will take commercially reasonable measures to make Subscribers and Relying Parties aware of their respective rights and obligations with respect to the operation and management of any keys, and/or certificates used in connection with the RSA CAs. Subscribers should also be notified as to procedures for dealing with suspected key compromise, certificate or key renewal, and service cancellation.

9.6.2 RA representations and warranties

No stipulation.

9.6.3 Subscriber representations and warranties

A Subscriber (Participating CA) will enter into an agreement that outlines the terms and conditions of use prior to the RSA CAs signing and issuing a CA certificate to the Subscriber. A Subscriber will:

• Have a CPS that has been approved by the RSA ROOT SIGNING SERVICE • Have proper insurance coverage • Have agreements with their Subscribers and Relying Parties, and • Agree to abide by the RSA ROOT SIGNING SERVICE CP • RSA will require, as part of the Subscriber Agreement, that the Subscriber make the

commitments and warranties set forth in Subscriber Agreement Requirements section of the CA/Browser Forum’s Guidelines for EV Certificates

9.6.4 Relying party representations and warranties

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 Agreement and RSA ROOT SIGNING SERVICE CP.

9.6.5 Representations and warranties of other participants

No stipulation.

9.7 Disclaimers of warranties The RSA CAs assume no liability except as stated in the relevant contracts pertaining to certificate issuance and management, such as a Subscriber Agreement or other relevant customer contract.



IN NO EVENT SHALL THE RSA ROOT SIGNING SERVICE BE LIABLE TO ANY PARTY FOR ANY INCIDENTAL, CONSEQUENTIAL, SPECIAL, INDIRECT OR PUNITIVE DAMAGES, LOST BUSINESS PROFITS, OR LOSS, DAMAGE OR DESTRUCTION OF DATA ARISING OUT OF OR RELATED IN ANY WAY TO THE CERTIFICATES ISSUED BY AN RSA CA, REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT (INCLUDING NEGLIGENCE), BREACH OF WARRANTY, OR OTHERWISE, EVEN IF THE RSA ROOT SIGNING SERVICE HAS BEEN ADVISED OF THE POSSIBILITY OF THE SAME. Nothing in the RSA ROOT SIGNING SERVICE CP or this CPS shall confer on any third party any authority to act for, bind, or create or assume any obligation or responsibility, or make any representation on behalf of another except as set forth in a relevant contract. Issuance of certificates in accordance with this policy does not make a CA an agent, partner, joint venture, fiduciary, trustee or other representative of Subscribers, customers or other Relying Parties. The relationship between a CA and the Subscriber is defined by the applicable contract.

9.8 Limitations of liability In no event will the RSA CAs be liable for any damages to Subscribers, Relying Parties or any other party arising out of or related to the misuse of, or reliance on Certificates issued by the CA that has been:

• Revoked or expired

• Used for unauthorized purposes

• Tampered with

• Compromised

• Subject to misrepresentation, misleading acts or omissions

9.9 Indemnities

Unless otherwise set forth in the RSA ROOT SIGNING SERVICE CP, this CPS and/or Subscriber Agreement and/or Relying Party Agreement, Subscriber and/or Relying Party hereby agrees to indemnify and hold RSA CAs harmless from any claims, actions or demands that are caused by the use or publication of a certificate and that arises from:

• Any false or misleading statement of fact by the Subscriber

• Any failure by the Subscriber to disclose a material fact, if such omission was made negligibly or with the intent to deceive

• Any failure on the part of the Subscriber to protect its Private Key and/or token if applicable, or to take the precautions necessary to prevent the compromise, disclosure, loss, modification or unauthorized use of the Subscriber's private key, or

• Any failure on the part of the Subscriber to promptly notify the RSA CAs of the compromise, disclosure, loss, modification or unauthorized use of the Subscriber's private key once the Subscribe has actual or constructive notice of such event

9.10 Term and termination

9.10.1 Term

This CPS remains in force until notice of the opposite is communicated by RSA. Inc. in writing directly to Participating CAs or by posting such notice on its web site at http://rsasecurity.com/products/keon/repository/practices.

9.10.2 Termination



Termination of this document will be upon publication of a newer version or replacement document, or upon termination of CA operations.

9.10.3 Effect of termination and survival

No stipulation.

9.11 Individual notices and communications with participants

The RSA ROOT SIGNING SERVICE will define in any applicable agreement the appropriate provisions governing severability, survival, merger or notice.

9.12 Amendments

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

9.12.1 Procedure for amendment

An electronic copy of RSA ROOT SIGNING SERVICE CPS is to be made available at the RSA. Inc. web site: http://www.rsasecurity.com/products/keon/repository/practices/RSA_KEON_ROOT_SIGNING_CA_CPS.pdf, or by requesting an electronic copy by e-mail to the contact representative as described in Section 1.5.

The RSA ROOT SIGNING SERVICE Policy Management Authority may notify, in writing, of any proposed changes to its CPS, if in the judgment and discretion of RSA ROOT SIGNING SERVICE Policy Management Authority the changes may have significant impact on its Subscriber community.

9.12.2 Notification mechanism and period

The notification shall contain a statement of proposed changes, the final date for receipt of comments, and the proposed effective date of change.

The comment period will be 30 days unless otherwise specified. The comment period will be defined in the notification.

9.12.3 Circumstances under which OID must be changed

If a policy change is determined by the RSA ROOT SIGNING SERVICE Policy Management Authority to warrant the issuance of a new policy, the RSA ROOT SIGNING SERVICE Policy Management Authority will assign a new Object Identifier (OID) for the new policy.

9.13 Dispute resolution provisions

Any dispute related to key and certificate management between an RSA ROOT SIGNING SERVICE and any other organization or individual outside the RSA ROOT SIGNING SERVICE shall be resolved using an appropriate dispute resolution mechanism. A dispute shall be resolved by negotiations if possible. RSA ROOT SIGNING SERVICE may define dispute resolution procedure in any agreement it enters into.

Any dispute not resolved by negotiations, mediation or arbitration shall be brought in the courts of the State of Massachusetts, or as otherwise agreed by the parties.



9.13.1 Negotiation The RSA ROOT SIGNING SERVICE and their Customer will attempt to resolve any controversy relating to an agreement, CP or associated statements of work by negotiations between representatives of the parties who have the authority to settle the controversy. These representatives will be appointed at time of contract along with a designate. A written notice stating the controversy and the requested remedy must be provided. This notice must be dated and signed by the appointed representative. All correspondence should be kept to a maximum of three (3) pages. The disputing party will provide written notice to the other party of the dispute. Within five (5) working days the receiving party will submit to the other a written response (maximum 3 pages). The appointed representatives will meet at an agreed time and place within five (5) business days from the date of the receiving party notice. The objective of the meeting is to negotiate resolution of the dispute.

9.13.2 Mediation In the event that negotiation fails to resolve the dispute within thirty (30) days the dispute will be submitted to mediation. The mediator will have no power to bind the parties. The mediation will be confidential and without prejudice. (i) Selection of Mediator Both parties will have three days to agree upon a mutually acceptable mediator. If no mediator has been selected both parties agree to request a local Alternative Dispute Resolution (ADR) Service Provider to provide a list of five (5) potential mediators. Both parties will agree to select one of the five candidates. (ii) Time and place for mediation Both parties, in consultation with the mediator, will agree on a mutual time and place for mediation. The date will be set within five (5) business days after the selection of the mediator. (iii) Fees of mediator The fees of the mediator will be shared equally by both parties. (iv) Termination of procedure Both parties agree to participate in mediation for at least four (4) hours. After that time either party may leave the mediation at any time. If the mediation does not yield a settlement then both parties agree not to take any action other than good faith attempts to negotiate a settlement of the dispute prior to a five (5) day post-mediation period.

9.13.3 Arbitration or litigation

In the event that negotiations and mediation fails then both parties may agree to binding arbitration or to litigate.

Arbitration

In the event of agreement on binding arbitration both parties will have five (5) business days from the end of the post-mediation period to agree on an arbitrator; both parties in consultation with the arbitrator will agree on the rules for the arbitration.

Litigation

In the event that either party decides to litigate, litigation shall be brought as stipulated in the RSA Root Signing Agreement.



9.14 Governing law

The RSA ROOT SIGNING SERVICE CPS and all corresponding agreements shall be governed by the laws of the Commonwealth of Massachusetts, without regard to its conflict of laws principles.

9.15 Compliance with applicable law

The RSA CAs will provide access to all information and facilities to law enforcement officials if required by law.

9.16 Miscellaneous provisions

9.16.1 Entire agreement

The RSA ROOT SIGNING SERVICE will define in any applicable agreement the appropriate provisions governing severability and survival of clauses, assignment of the agreement and notice requirements.

9.16.2 Assignment

Subscribers and Relying Parties may not assign any of their rights or obligations under their applicable agreements, without the written consent of RSA ROOT SIGNING SERVICE.

9.16.3 Severability

The RSA ROOT SIGNING SERVICE will define in any applicable agreement the appropriate provisions governing severability.

9.16.4 Enforcement (attorneys' fees and waiver of rights)

The RSA ROOT SIGNING SERVICE will define in any applicable agreement the appropriate provisions governing enforcement.

9.16.5 Force Majeure

The RSA ROOT SIGNING SERVICE shall not be held responsible for any delay or failure in performance of its obligations hereunder to the extent such delay or failure is caused by fire, flood, strike, civil, governmental or military authority, acts of terrorism or war, act of God, or other similar causes beyond its reasonable control and without the fault or negligence of the RSA ROOT SIGNING SERVICE or its subcontractors.

9.17 Other provisions

No stipulation.



10 ACRONYMS ASN.1 Abstract Syntax Notation number One CA Certification Authority CP Certificate Policy CPS Certification Practice Statement CRL Certificate Revocation List DN Distinguished Name DSA Digital Signature Algorithm EAL Evaluation Assurance Level EV Extended Validation FIPS Federal Information Processing Standard HSM Hardware Security Module IETF Internet Engineering Task Force ITU International Telecommunications Union LDAP Lightweight Directory Access Protocol MD5 Message Digest 5 OCSP Online Certificate Status Protocol PIN Personal Identification Number PKCS Public-Key Cryptography Standards PKI Public Key Infrastructure PKIX Public Key Infrastructure X.509 RA Registration Authority RFC Request For Comment RSA Rivest-Shamir-Adleman SHA –1 Secure Hash Algorithm S/MIME Secure Multipurpose Internet Mail

Extension SSL Secure Sockets Layer URI Uniform Resource Identifier URL Uniform Resource Locator



11 DEFINITIONS A TERM: Access control DEFINITION: The granting or denial of use or entry. TERM: Activation Data DEFINITION: Activation data, in the context of certificate enrollment, consists of a one-time secret communicated to the enrolling user (Subscriber) out of band. This shared secret permits the user to complete of the enrollment process. TERM: Administrator DEFINITION: A Trusted Person within the organization of a Processing Center, Service Center, Managed PKI Customer, or Gateway Customer that performs validation and other CA or RA functions. TERM: Administrator Certificate DEFINITION: A Certificate issued to an Administrator that may only be used to perform CA or RA functions. TERM: Agent DEFINITION: A person, contractor, service provider, etc. that is providing a service to an organization under contract and are subject to the same corporate policies as if they were an employee of that organization. TERM: Application Server DEFINITION: An application service that is provided to an organization or one of its collaborative partners and may own a certificate issued under the organizational PKI. Examples are Web SSL servers, VPN servers (IPSec), object signer services, Domain Controllers, etc. TERM: Authentication DEFINITION: The act of verifying; in the case of identities, the assurance of an identity. TERM: Authorization DEFINITION: The granting of permissions of use. B TERM: business process DEFINITION: A set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships. C TERM: certificate DEFINITION: The public key of a user, together with related information, digitally signed with the private key of the Certification Authority that issued it. The certificate format is in accordance with ITU-T Recommendation X.509. TERM: Certification Authority (CA) DEFINITION: An authority trusted by one or more users to manage X.509 certificates and CRLs. TERM: CA (Certification Authority) room / facility



DEFINITION: The room or facility where the CA systems and components are enclosed, and which the PKI Policy Management Authority has control regarding who has access to this room or facility. TERM: Certification Chain DEFINITION: An ordered list of Certificates containing an end-user Subscriber Certificate and CA Certificates, which terminates in a root Certificate. TERM: Certificate Policy DEFINITION: Named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements. It is the principal statement of certificate policy governing the organizational PKI. The CP is a high-level document that describes the requirements, terms and conditions, and policy for issuing, utilizing and managing certificates issued by a CA. TERM: Certification Practice Statement DEFINITION: A statement of the practices, which a Certification Authority employs in issuing certificates. It is a comprehensive description of such details as the precise implementation of service offerings and detailed procedures of certificate life-cycle management and will be more detailed than the certificate policies supported by the CA. TERM: Certificate Revocation List DEFINITION: A periodically issued list, digitally signed by a CA, of identified Certificates that have been revoked prior to their expiration dates. The list generally indicates the CRL issuer’s name, the date of issue, the date of the next scheduled CRL issue, the revoked Certificates’ serial numbers, and the specific times and reasons for revocation. CRL can be used to check the status of certificates. TERM: Common Criteria DEFINITION: The Common Criteria is an Internal agreed upon IT Security evaluation criteria. It represents the outcome of a series of efforts to develop criteria for evaluation of IT security that are broadly useful within the international community. TERM: confidential DEFINITION: A security classification used to describe information which if disclosed could result in personal loss or minor financial loss. Personal information and tactical information would be deemed confidential. TERM: Confidentiality DEFINITION: Information that has an identifiable value associated with it such that if disclosed might cause damage to an entity. TERM: Cross Certification DEFINITION: The process describing the establishing of trust between two or more CAs. Usually involves the exchange and signing of CA certificates and involves the verification of assurance levels. D TERM: Distinguished Encoding Rules (DER) DEFINITION: The Distinguished Encoding Rules for ASN.1, abbreviated DER, gives exactly one way to represent any ASN.1 value as an octet string. DER is intended for applications in which a unique octet string encoding is needed, as is the case when a digital signature is computed on an ASN.1 value.



TERM: Digital Signature DEFINITION: The result of the transformation of a message by means of a cryptographic system using keys such that a person who has the initial message can determine that the key that corresponds to the signer’s key created the transformation and the message was not altered. TERM: Distinguished Name (DN) DEFINITION: Every entry in a X.500 or LDAP directory has a Distinguished Name, or DN. It is a unique entry identifier through out the complete directory. No two Entries can have the same DN within the same directory. A DN is used in certificates to uniquely identify a certificate-owner. Example of a DN:

cn=Road Runner, ou=bird, dc=carton, dc=com ou=bird, dc=carton, dc=com dc=carton, dc=com dc=com

TERM: Dual Control DEFINITION: A process utilizing two or more separate entities (usually persons), operating in concert, to protect sensitive functions or information, whereby no single entity is able to access or utilize the materials, e.g., cryptographic key. E TERM: E-mail Certificates DEFINITION: Certificates utilized for encrypting and verifying digital signatures. Normally two separate certificate: one for encryption, the other for signature verification. TERM: Entity DEFINITION: Any autonomous element or component within the Public Key Infrastructure that participate is one form or another, such managing certificates or utilizing certificates. An Entity can be a CA, RA, Subscriber, Relying Party, etc. F TERM: FIPS 140-2 DEFINITION: Federal Information Processing Standard 140-2(FIPS 140-2) is a standard that describes US Federal government requirements that IT products shall meet for Sensitive, but Unclassified (SBU) use. The standard was published by the National Institute of Standards and Technology (NIST), has been adopted by the Canadian government's Communication Security Establishment (CSE), and is likely to be adopted by the financial community through the American National Standards Institute (ANSI). The different levels (1 to 4) within the standard provide different levels of security and in the higher levels have different documentation requirements. TERM: FIPS 180-1 DEFINITION: Standard specifying a Secure Hash Algorithm, SHA-1, for computing a condensed representation of a message or a data files. G H I TERM: Integrity DEFINITION: Ensuring consistency of an object or information. Within security systems, integrity is the principle of ensuring that a piece of data has not been modified maliciously or accidentally.



TERM: ISO 9564-1 DEFINITION: Basic principles and requirements for online PIN handling in ATM and POS systems, provides instructions to financial institutions in the development, implementation and/or the operation of systems and procedures for the protection of PIN throughout its lifecycle. TERM: ISO 11568-5 DEFINITION: Basic principles and requirements for Key lifecycle for public key cryptosystems, provides instructions to financial institutions in the development, implementation and/or the operation of systems and procedures throughout Key’s lifecycle J K TERM: Key DEFINITION: When used in the context of cryptography, it is a secret value, a sequence of characters that is used to encrypt and decrypt data. A key is a unique, generated electronic string of bits used for encrypting, decrypting, e-signing or validating digital signatures. TERM: Key Pair DEFINITION: Often referred to as public/private key pair. One key is used for encrypting and the other key used for decrypting. Although related, the keys are sufficiently different that knowing one does not allow derivation or computation of the other. This means that one key can be made publicly available without reducing security, provided the other key remains private. L M TERM: MD5 DEFINITION: One of the message digest algorithms developed by RSA. N TERM: non-repudiation DEFINITION: Protection against the denial of the transaction or service or activity occurrence. O TERM: Object Identifier DEFINITION: The unique alpha-numeric identifier registered under the ISO registration standard to reference a standard object or class. P TERM: PKCS #1 DEFINITION: Standard that provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering the following aspects: cryptographic primitives; encryption schemes; signature schemes, etc. TERM: PKCS #7 DEFINITION: A cryptographic message format or syntax managed and edited by RSA Laboratories. A standard describing general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. TERM: PKCS #10 DEFINITION: A certificate request format or syntax managed and edited by RSA Laboratories. It is a standard describing syntax for a request for certification of a public key, a name, and possibly a set of attributes. TERM: PKIX DEFINITION: The Public Key Infrastructure (X.509) or PKIX is an IETF Working Group established with the intent of developing Internet standards needed to support an X.509-based



PKI. The scope of PKIX extends to also develop new standards for use of X.509-based PKIs in the Internet. TERM: PKI personnel DEFINITION: Persons, generally employees, associated with the operation, administration and management of a CA or RA. TERM: policy DEFINITION: The set of laws, rules and practices that regulates how an organization manages its business. Specifically, security policy would be the set of laws, rules and practices that regulates how an organization manages, protects and distributes sensitive information. TERM: PrintableString DEFINITION: String format for representing names, such as Common Name (CN), in X.509 certificates. The encoding of a value in this syntax is the string value itself. TERM: Private Key DEFINITION: The private key is one of the keys in a public/private key pair. This is the key that is kept secret as opposed to the other key that is publicly available. Private keys a utilized for digitally signing documents, uniquely authenticating an individual, or decrypting data that was encrypted with the corresponding public key. TERM: Public Key Infrastructure DEFINITION: A set of policies, procedures, technology, audit and control mechanisms used for the purpose of managing certificates and keys. TERM: Public DEFINITION: A security classification for information that if disclosed would not result in any personal damage or financial loss. TERM: Public Key DEFINITION: The community verification key for digital signature and the community encryption key for encrypting information to a specific Subscriber. Q R TERM: Registration Authority DEFINITION: An entity that performs registration services on behalf of a CA. RAs work with a particular CA to vet requests for certificates that will them be issued by the CA. TERM: Rekey DEFINITION: The process of replacing or updating the key(s). The expiration of the crypto period involves the replacement of the public key in the certificate and therefore the generation of a new certificate. RSA ROOT SIGNING SERVICE does not support rekey. TERM: Relative Distinguished Name (RDN) DEFINITION: A Distinguished Name is made up of a sequence of Relative Distinguished Names, or RDNs. The sequences of RDNs are separated by commas (,) or semi-colons (;). There can be more than one identical RDN in a directory, but they must be in different bases, or branches, of the directory. Example of a DN is “cn=Road Runner,ou=bird,dc=carton,dc=com”

RDNs would be: RDN => cn=Road Runner RDN => ou=bird RDN => dc=carton RDN => dc=com



TERM: Relying Party DEFINITION: A person or entity that uses a certificate signed by the CA to authenticate a digital signature or encrypt communications to a certificate subject. The relying party relies on the certificate as a result of the certificate being sign by a CA, which is trusted. A relying party normally is but does not have to be a Subscriber of the PKI. TERM: Repository DEFINITION: A place or container where objects are stored. A data repository is technology where data is stored logically. In PKI terms, a repository accepts certificates and CRLs form one or more CAs and makes them available to entities that need them for implementing security services. TERM: Revocation DEFINITION: In PKI, revocation is the action associated with revoking a certificate. Revoking a certificate is to make the certificate invalid before its normal expiration. The Certification Authority that issued the certificate is the entity that revokes a certificate. The revoked status is normally published on a certificate revocation list (CRL). TERM: RSA DEFINITION: A public key cryptographic algorithm invented by Rivest, Shamir, and Adelman. S TERM: Sensitive DEFINITION: Used to describe the security classification of information where the information if disclosed would result in serious financial loss, serious loss in confidence or could result in personal harm or death. TERM: Signature Verification Certificate DEFINITION: Often referred to as simply a Signature Certificate. It is the certificate containing the public key used to verify a digital signature that was signed by the corresponding private key. TERM: Split Knowledge DEFINITION: A condition under which two or more parties separately and confidentially have custody of components of a single key that, individually, convey no knowledge of the resultant cryptographic key. The resultant key exists only within secure cryptographic devices TERM: SSL Client Certificate DEFINITION: Certificate utilized to verify the authentication of an end user to a server when a connection is being established via a SSL session (secure channel). TERM: SSL Server Certificate DEFINITION: Certificate utilized to verify the authentication of a web or application server to the end user (client) when a connection is being established via a SSL session (secure channel). TERM: Subscriber DEFINITION: A Subscriber is an entity; a person or application server that is a holder of a private key corresponding to a public, and has been issued a certificate. In the case of an application server, a person authorized by the organization owning the application server may be referred to as the Subscriber. A Subscriber is capable of using, and is authorized to use, the private key that corresponds to the public key listed in the certificate. TERM: Surveillance Camera DEFINITION: A surveillance camera is a video recording device used for detection and identification of unauthorized physical entry to a secured area. A camera used for recording a signing ceremony for auditing purposes is not considered a surveillance camera.



T TERM: threat DEFINITION: A danger to an asset in terms of that asset's confidentiality, integrity, availability or legitimate use. TERM: Token DEFINITION: Hardware devices normally associated with a reader, used to store and/or generate encryption keys, such as smartcards and USB tokens. U TERM: URI DEFINITION: Universal Resource Indicator - an address on the Internet. TERM: UTF8String DEFINITION: UTF-8 is a type of Unicode, which is a character set supported across many commonly used software applications and operating systems. UTF-8 is a multi-byte encoding in which each character can be encoded in as little as one byte and as many as four bytes. Most Western European languages require less than two bytes per character. Greek, Arabic, Hebrew, and Russian require an average of 1.7 bytes. Japanese, Korean, and Chinese typically require three bytes per character. Such Unicode is important to ensure universal character / foreign characters are supported. V TERM: Vettor DEFINITION: A person who verifies information provided by a person applying for a certificate. TERM: vulnerability DEFINITION: Weaknesses in a safeguard or the absence of a safeguard. W X TERM: X.500 DEFINITION: Specification of the directory service required to support X.400 e-mail initially but common used by other applications as well. TERM: X501PrintableString DEFINITION: String format for representing names, such as Common Name (CN), in X.509 certificates. The encoding of a value in this syntax is the string value itself; an arbitrary string of printable characters. TERM: X.509 DEFINITION: An ISO standard that describes the basic format for digital certificates. Y Z